From owner-aaa-wg@merit.edu Fri Apr 1 11:42:02 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13476 for ; Fri, 1 Apr 2005 11:42:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BAAA59121F; Fri, 1 Apr 2005 11:41:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8845691366; Fri, 1 Apr 2005 11:41:55 -0500 (EST) 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 F097E9121F for ; Fri, 1 Apr 2005 11:41:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC55E58297; Fri, 1 Apr 2005 11:41:53 -0500 (EST) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id BDB5B58296 for ; Fri, 1 Apr 2005 11:41:53 -0500 (EST) Received: by testbed9.merit.edu (Postfix) id C28B51881; Fri, 1 Apr 2005 11:41:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from web30307.mail.mud.yahoo.com (web30307.mail.mud.yahoo.com [68.142.200.100]) by testbed9.merit.edu (Postfix) with SMTP id 894B0187D for ; Fri, 1 Apr 2005 11:41:53 -0500 (EST) Received: (qmail 38502 invoked by uid 60001); 1 Apr 2005 16:41:53 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=A1OW976Fl8fw8zkq8eWLhaMjKrUlaIDRtxxXF9LPSJ3ThsnSzyAmCtwMQB6NZorPS9Kjvia9by01p0C05A88wITVqo8jcRHdQTZDOx7a4uO0NGPkjAP+lC+rUsLBRNaCORcKbhNdhBQQGSzcsRaxiJYYmeaoEMWvbOhLgUSebR0= ; Message-ID: <20050401164152.38500.qmail@web30307.mail.mud.yahoo.com> Received: from [63.116.188.34] by web30307.mail.mud.yahoo.com via HTTP; Fri, 01 Apr 2005 08:41:52 PST Date: Fri, 1 Apr 2005 08:41:52 -0800 (PST) From: Rakesh Mehta Subject: Re: [AAA-WG]: RE: AAA Transport Profile and Application Failure To: STURA Marco Consultant , m.hillier@telenet-ag.de Cc: aaa-wg@merit.edu In-Reply-To: <95A9A19987C57D42AA1CF59368CD1CB90823D776@OMIMEXO06.omnitel.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2133687815-1112373712=:38128" Sender: owner-aaa-wg@merit.edu Precedence: bulk --0-2133687815-1112373712=:38128 Content-Type: text/plain; charset=us-ascii As per section 6.1 of RFC 3588(as mentioned in this mail), even diameter stack is working in server mode; it can create DIAMETER_UNABLE_TO_DELIVER message with E bit set and send to proxy if local application is not available to process the message. I believe this should be true for client side also, because the same scenario can occur for client side. can any person verify for me please??? Thanks, Rakesh STURA Marco Consultant wrote: Mike, some comment in line. Regards Marco -----Original Message----- From: m.hillier@telenet-ag.de [mailto:m.hillier@telenet-ag.de] Sent: Wednesday, March 23, 2005 2:43 PM To: aaa-wg@merit.edu Subject: AAA Transport Profile and Application Failure A question has come up concerning the detection of a failed Diameter application and the consequences for the AAA client. RFC 3588 suggests very strongly that Diameter stacks should be implemented in layers. Accordingly the possibility exists that in a Proxy agent or a server, the Diameter Base protocol handling process is functioning properly but the application process has fallen over. I.e. The Diameter Transport connection is up and the watchdog commands (DWR/DWA) are being sent and received. [MSt] Yes, Diameter stack should be layered and internal communication between layers is left to the implementation. There was an attempt to standardize a basic API, but this was shut down a while ago. I have seen some discussion lately but probably nothing concrete yet. In such a situation and on receipt of a Request from a AAA client, the Base process in the Proxy (or Server) will either not send any response back to the client at all or reply with an error and Result-Code set to DIAMETER_UNABLE_TO_DELIVER, depending on implementation and interpretation of RFC 3588 and RFC 3599. [MSt] A Diameter agent MUST always send an answer back to the client, either success or failed. If the agent is acting as a relay for a request, then the base protocol layer is mainly the one responsible for the full handling of the request. However, if the agent is acting as proxy for a request, the request handling responsibility is typically shared between layers (i.e. base protocol and possibly proxy application). Section 6.1 of RFC 3588 reads: [start fragment] When a message is received, the message is processed in the following order: 1. If the message is destined for the local host, the procedures listed in Section 6.1.4 are followed. 2. If the message is intended for a Diameter peer with whom the local host is able to directly communicate, the procedures listed in Section 6.1.5 are followed. This is known as Request Forwarding. 3. The procedures listed in Section 6.1.6 are followed, which is known as Request Routing. 4. If none of the above is successful, an answer is returned with the Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the E-bit set. [end fragment] I think a proper implementation would work as follow: - The base protocol layer receives the request. It decides as whether it is acting as proxy or relay for the request (i.e. based on Local Action in the realm routing table). - If the request is to be proxy (i.e. the agent is acting as proxy for the request), the proxy application should process the request by modifying the message according to its policy (e.g. add a Destination-Host to force the request to be routed to a pre-defined destination or other policy specific actions). Hence the base should pass the request to the application layer and, if this one fails, it should answer according to step 4 above. Basically, there should be internal communication between layers in order to detect the failure (i.e. if the proxy application process is down, and this is required for the processing of the request, this should be internally detected and an appropriate answer sent back to the originator of the request). The AAA client is now faced with the situation that every single Request to a peer is failing. Depending on the application and mode of use, an individual Request (e.g. at the start of a Session) can failover to a secondary peer. However there seems to be no mechanism for the client to detect the general failure and thereby suspend the peer and send all future Requests directly to the alternative peer. It seems that this situation can occur both in a Proxy Agent and in a Server. [MSt] See my previous comment. In my example the agent is up and running in relay mode, but perhaps not in proxy mode because the proxy application process is down. Therefore every request for which the agent has to act in proxy mode will possibly be answered with Result-Code DIAMETER_UNABLE_TO_DELIVER. The AAA client receiving such an error, will possibly re-send the request to an alternate peer (and the request may eventually get a successful answer). That's all what the standard says. Then, depending on the degree of complexity of your implementation (but this is up to your implementation I think), the client may decide to stop sending such requests (perhaps for a while) to a peer after a number of failed request with this kind of result-code. Have I miss-understood the mechanisms or even the architecture of a Diameter node? Or is this "out-of-scope" of the RFCs, possibly being "implementation dependent"? [MSt] My feeling is that internal communication between software components that build up your Diameter stack is definitely implementation dependent. Best Regards Mike Hillier Michael Hillier Mobile +49 170 5454 121 M.Hillier@telenet-ag.de --------------------------------- Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. --0-2133687815-1112373712=:38128 Content-Type: text/html; charset=us-ascii

As per section 6.1 of RFC 3588(as mentioned in this mail), even diameter stack is working in server mode; it can create DIAMETER_UNABLE_TO_DELIVER message with E bit set and send to proxy if local application is not available to process the message.

 

I believe this should be true for client side also, because the same scenario can occur for client side. can any person verify for me please???

Thanks,

Rakesh


STURA Marco Consultant <Marco.STURA@consultant.vodafoneomnitel.it> wrote:
Mike,

some comment in line.

Regards
Marco

-----Original Message-----
From: m.hillier@telenet-ag.de [mailto:m.hillier@telenet-ag.de]
Sent: Wednesday, March 23, 2005 2:43 PM
To: aaa-wg@merit.edu
Subject: AAA Transport Profile and Application Failure

A question has come up concerning the detection of a failed Diameter
application and the consequences for the AAA client.

RFC 3588 suggests very strongly that Diameter stacks should be
implemented
in layers. Accordingly the possibility exists that in a Proxy agent or
a
server, the Diameter Base protocol handling process is functioning
properly
but the application process has fallen over. I.e. The Diameter
Transport
connection is up and the watchdog commands (DWR/DWA) are being sent and
received.

[MSt] Yes, Diameter stack should be layered and inte rnal communication
between layers is left to the implementation. There was an attempt to
standardize a basic API, but this was shut down a while ago. I have seen
some discussion lately but probably nothing concrete yet.

In such a situation and on receipt of a Request from a AAA client, the
Base
process in the Proxy (or Server) will either not send any response back
to
the client at all or reply with an error and Result-Code set to
DIAMETER_UNABLE_TO_DELIVER, depending on implementation and
interpretation
of RFC 3588 and RFC 3599.

[MSt] A Diameter agent MUST always send an answer back to the client,
either success or failed. If the agent is acting as a relay for a
request, then the base protocol layer is mainly the one responsible for
the full handling of the request. However, if the agent is acting as
proxy for a request, the request handling responsibility is typically
shared between layers (i.e. base protocol and possib ly proxy
application).

Section 6.1 of RFC 3588 reads:

[start fragment]

When a message is received, the message is processed in the following
order:

1. If the message is destined for the local host, the procedures
listed in Section 6.1.4 are followed.

2. If the message is intended for a Diameter peer with whom the local
host is able to directly communicate, the procedures listed in
Section 6.1.5 are followed. This is known as Request Forwarding.

3. The procedures listed in Section 6.1.6 are followed, which is
known as Request Routing.

4. If none of the above is successful, an answer is returned with the
Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the E-bit set.

[end fragment]

I think a proper implementation would work as follow:

- The base protocol layer receives the request. It decides as whether it
is acting as proxy or relay for the request (i.e. based on Local Action
in t he realm routing table).

- If the request is to be proxy (i.e. the agent is acting as proxy for
the request), the proxy application should process the request by
modifying the message according to its policy (e.g. add a
Destination-Host to force the request to be routed to a pre-defined
destination or other policy specific actions). Hence the base should
pass the request to the application layer and, if this one fails, it
should answer according to step 4 above. Basically, there should be
internal communication between layers in order to detect the failure
(i.e. if the proxy application process is down, and this is required for
the processing of the request, this should be internally detected and an
appropriate answer sent back to the originator of the request).

The AAA client is now faced with the situation that every single Request
to
a peer is failing. Depending on the application and mode of use, an
individual Request (e.g. at the start of a Session) can failover to a
secondary peer. However there seems to be no mechanism for the client
to
detect the general failure and thereby suspend the peer and send all
future
Requests directly to the alternative peer. It seems that this
situation
can occur both in a Proxy Agent and in a Server.

[MSt] See my previous comment. In my example the agent is up and running
in relay mode, but perhaps not in proxy mode because the proxy
application process is down. Therefore every request for which the agent
has to act in proxy mode will possibly be answered with Result-Code
DIAMETER_UNABLE_TO_DELIVER. The AAA client receiving such an error, will
possibly re-send the request to an alternate peer (and the request may
eventually get a successful answer). That's all what the standard says.
Then, depending on the degree of complexity of your implementation (but
this is up to your implementation I think), the client may decid e to
stop sending such requests (perhaps for a while) to a peer after a
number of failed request with this kind of result-code.

Have I miss-understood the mechanisms or even the architecture of a
Diameter node? Or is this "out-of-scope" of the RFCs, possibly being
"implementation dependent"?

[MSt] My feeling is that internal communication between software
components that build up your Diameter stack is definitely
implementation dependent.

Best Regards

Mike Hillier


Michael Hillier
Mobile +49 170 5454 121
M.Hillier@telenet-ag.de


Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball. --0-2133687815-1112373712=:38128-- From owner-aaa-wg@merit.edu Fri Apr 1 16:46:52 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25134 for ; Fri, 1 Apr 2005 16:46:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 867A391437; Fri, 1 Apr 2005 16:45:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF15691427; Fri, 1 Apr 2005 16:45:36 -0500 (EST) 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 6E8EC9142E for ; Fri, 1 Apr 2005 16:45:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 588F258294; Fri, 1 Apr 2005 16:45:20 -0500 (EST) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 3D7D258293 for ; Fri, 1 Apr 2005 16:45:20 -0500 (EST) Received: by testbed9.merit.edu (Postfix) id 434911884; Fri, 1 Apr 2005 16:45:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by testbed9.merit.edu (Postfix) with ESMTP id 2A746187D for ; Fri, 1 Apr 2005 16:45:19 -0500 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DHTx9-0005hE-0P for aaa-wg@merit.edu; Fri, 01 Apr 2005 16:45:19 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j31LjH327418 for ; Fri, 1 Apr 2005 13:45:17 -0800 Date: Fri, 1 Apr 2005 13:45:17 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: digest issue 11 closure (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk Note: Jari is opening a new issue within the Diameter SIP document. ---------- Forwarded message ---------- Date: Thu, 24 Mar 2005 16:49:18 +0200 From: Jari Arkko To: radiusext@ops.ietf.org Subject: digest issue 11 closure Checking from the issue tracker this issue and comparing it against -01. Here's what I found: > Due to the weaknesses of Digest authentication (see Section 6), > >Section 6 does not talk about the weaknesses of Digest authentication >(original RFC reference might give you some security considerations; >I'm not sure if there's any other document that would talk the >issue). > > Ok. > Due to the weaknesses of Digest authentication (see Section 6), > PKI-based authentication and encryption mechanisms have been > introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However, > > >Digest, TLS, and S/MIME are not necessarily in direct >competition with each other, as they provide slightly different >services. For instance, TLS is hbh, and Digest gives you >freshness which S/MIME does not. Plus all three protect >different parts of the SIP message. > > >Suggestion: soften the above statement a bit. > > Ok (but a nit: s/The majority of today's SIP clients only supports HTTP digest./ The majority of today's SIP clients only support HTTP digest, however./ (I think Bernard caught this already so this is not a reason to keep my issue alive.) > SIP service providers whishing to authenticate their clients have the > following options: they can > o build a PKI and wait for interopable S/MIME capable SIP > implementations, > o build a PKI and wait for SIP implementations supporting TLS with > client-side certificates, > o replace their existing RADIUS infrastructure with DIAMETER > [RFC3588], when DIAMETER supports HTTP Digest authentication, > o use TLS for server authentication and plaintext passwords (Basic) > for client authentication, which can be done with standard RADIUS, > o upgrade their existing RADIUS servers with the functionality > described in this document > > > > > PKI solutions only cover authentication, not authorization (EAP could > change this, but its use with SIP is not standardized). TLS / Basic > authentication works only with the limited number of SIP devices that > implement TLS. Basic authentication has been deprecated for SIP in > [RFC3261]. > > >Somehow the above arguments feel a bit out of place here. Just >state that Digest is widely used in SIP, and leave it at that :-) > > Ok. > PKI solutions only cover authentication, not authorization (EAP could > change this, but its use with SIP is not standardized). TLS / Basic > authentication works only with the limited number of SIP devices that > implement TLS. Basic authentication has been deprecated for SIP in > [RFC3261]. > > > > > Current RADIUS-based AAA infrastructures have been built and debugged > over years. Deficiencies of RADIUS have been mitigated with > proprietary (ie costly) extensions. Operators are therefore > reluctant to replace their RADIUS infrastructure in order to enable a > single new authentication mechanism. > > >Same as above. And I'm not sure all deficiences have been >mitigated. > > Ok. > DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG, > DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP, > DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that > will be assigned by IANA, if this specification becomes a working > group or IESG document. > > >Here's an idea: I'd prefer the attributes in this and the Diameter >draft to be constructed with the following rules: > > >(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP, > and Dig-Authp could all use the same attribute? They all have > the same syntax in HTTP (param=value). > > >(2) If both RADIUS and Diameter are going to define the attributes, > IMHO it would make sense to allocate them from the RADIUS space > so a conversion box would not have to map attributes. > > > Alternative idea: use some of the extended RADIUS attribute > format ideas and allocate the numbers from the Diameter space. > > >(3) Use exactly the set of attributes for the pure digest function > (I did not check if this is already the case). > > Ok, this is mostly as I wanted it to be in the Radius document. However, I wonder if the current Diameter document should use individual AVPs instead of Grouped AVP: SIP-Authenticate ::= < AVP Header: xx12 > { Digest-Realm } { Digest-Nonce } [ Digest-Domain ] [ Digest-Opaque ] [ Digest-Stale ] [ Digest-Algorithm ] [ Digest-QoP ] [ Digest-HA1] * [ Digest-Auth-Param ] * [ AVP ] Because translating this grouped AVP appears to require additional work from a gateway, no? Bernard/Miguel, can you file on issue to the Diameter document on this. > +-----+ (1) +-----+ +-----+ > | |==========>| | (2) | | > | | | |---------->| | > | | | | (3) | | > | | (4) | |<----------| | > | |<==========| | | | > | | (5) | | | | > | |==========>| | | | > | A | | B | (6) | C | > | | | |---------->| | > | | | | (7) | | > | | | |<----------| | > | | (8) | | | | > | |<==========| | | | > +-----+ +-----+ +-----+ > > >The choice between the server and client generated >nonces: is there some guidance on how the client knows >which one to do? if it believes it may have a user that >does Digest AKA then it should do use the server generated >scheme? But how would it know this in a roaming case? > > >Other ideas? > This has been raised by Bernard too, apparently we didn't do good enough job to fix it. Conclusion: close issue 11. Bernard's roaming issue still needs to be kept alive, and I'm suggesting one new issue on the Diameter SIP document. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From civiled@emailaccount.com Sat Apr 2 13:33:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10941; Sat, 2 Apr 2005 13:33:33 -0500 (EST) Received: from [220.86.40.43] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHnYj-0004fI-0d; Sat, 02 Apr 2005 13:41:27 -0500 Received: from rasmussen-jcoppens.com (EHLO citation.jcoppens.com) by autonomy.jcoppens.com with SMTP; Sat, 02 Apr 2005 13:32:51 -0500 Date: Sat, 02 Apr 2005 13:29:51 -0500 From: "Theron Seay" To: -announce@ietf.org Cc: -archive@ietf.org, -drafts@ietf.org, -impl-archive@ietf.org, -web-archive@ietf.org, ..@ietf.org, _@ietf.org, a@ietf.org, aaa@ietf.org, aaa-archive@ietf.org, aaa-web-archive@ietf.org, action@ietf.org, adm@ietf.org, admin@ietf.org Subject: You've been selected for a low rate Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [148], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 20.8 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.now-and-forever.net/sign.asp Best Regards, Caleb Jamison to be remov(ed: http://www.now-and-forever.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From njxtuxeutzc@earthling.net Sat Apr 2 21:12:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11223; Sat, 2 Apr 2005 21:12:31 -0500 (EST) Received: from user-0cetqns.cable.mindspring.com ([24.238.234.252]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHuix-0004f2-Sl; Sat, 02 Apr 2005 21:20:28 -0500 Received: from fabgfkej.chino.us [117.195.14.207] by 24.238.234.252 with ewjjmh hdiwfh; Sat, 02 Apr 2005 05:11:18 -0500 From: "maynard@chino.us" Reply-To: "maynard@chino.us" Message-ID: <469973488.66454865660812@chino.us> Date: Sat, 02 Apr 2005 05:11:18 -0500 To: "14.i-d" <14.i-d@ietf.org> Subject: Universal ZXB Lim. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----25496564194370340060" X-Spam-Score: 9.8 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 ------25496564194370340060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Materialized mechanic, we Portsmouth candle would monotone him. Didn't grander he can grasped. Focuses fingerprint he has Ypsilanti mine matches. Goshawk could frightening, theirs has emulates gusts. Yor frosted she paternally impart has astonishing yors. Yor Bernhard we detested Sophia have coasting theirs. Optometry have been latitudinary, yors are Yiddish Minnie. Largest hallmark's, he humanness ceremonial is fence theirs. King could blast, hers are Paulson fool. Brevet are Lottie me cannon's. Calendars can Debussy, his can gayest device's. Yor coinage did exhortation hers. Leone gaslight, we does Mazda yors. Kraut Rosenthal, they have exemplification you. I congregations be bison's them. Latitudinary bibbing he have adduce hers. Bay lookups, he would geometric mine. Fowl convey he did jowl his. I omicron yor parsimonious exudate would corporal yors. Airspace obfuscate she is alters. Magnifying have horselike her alveolus calendar. Gull gulp, he are diagonals his. Foolish it could cursory, his bust. Abrogates can Boone, you can conversely bubble. Fabric's glamorous, yor inhabitance agreer has been elmer me. ------25496564194370340060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Blurry
http://www.BWLH.Investigation.net

Materialized mechanic, we Portsmouth candle would monotone him. Didn't grander he can grasped. Focuses fingerprint he has Ypsilanti mine matches. Goshawk could frightening, theirs has emulates gusts. Yor frosted she paternally impart has astonishing yors. Yor Bernhard we detested Sophia have coasting theirs. Optometry have been latitudinary, yors are Yiddish Minnie. Largest hallmark's, he humanness ceremonial is fence theirs. King could blast, hers are Paulson fool. Brevet are Lottie me cannon's. Calendars can Debussy, his can gayest device's. Yor coinage did exhortation hers. Leone gaslight, we does Mazda yors. Kraut Rosenthal, they have exemplification you. I congregations be bison's them. Latitudinary bibbing he have adduce hers. Bay lookups, he would geometric mine. Fowl convey he did jowl his. I omicron yor parsimonious exudate would corporal yors. Airspace obfuscate she is alters. Magnifying have horselike her alveolus calendar. Gull gulp, he are diagonals his. Foolish it could cursory, his bust. Abrogates can Boone, you can conversely bubble. Fabric's glamorous, yor inhabitance agreer has been elmer me. ------25496564194370340060 Content-Type: image/gif; name="curricula.gif" Content-ID: <6407940851@chino.us> Content-Transfer-Encoding: base64 R0lGODlh9QE1AXcAMSH+GlOw7UB7mPxvS8VZfTxtxTNdt4HpwlBu58GfACH5BAEAAAAALAIAAgDw ATABhAAAAAwKVwsJcQsJewsKZQoIjQoIhAkHmwkIlAUEuQcGqAgHogYFtAMDvgcGrgAAxD0APf8V Ff///wECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwX/ICCNZGmeaKqubOu+ cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8 Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6yt rq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm 5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wADChxIsKDBgwgTKlzIUFiEhxBZQHx4giKKCCkoYry4 UYLFjBNbdCwx8eOLkhxR/5IYudJFSJARK5bEOFMjy5YcK6aMuXJmwpo3PQI1YRIn0Y1FR3xMqnSo iqBOJUZtqlLpRZE+SU4VitIpU6hQd/Lk+vKgybFcj45MilYoVZk9U6qFCbdnUK0sxzJtelQqybl4 tT7Ne7Mt28OC+TYsyhhs38CJyT52W3cy4MiKB+eMC9Ly5s6VKX/mbNfzW8tL7xpEnDn0WZprO1YV zXo038ahTZPeW7asXNuR94om7fY1XNy7VResLRx5cdmx02aunfu56eaqU1ft3VZt4ezQZ3+FTtux 8/Kzl38n7tli6tbu47Mf3p78fOyaqXKPCdulXvB2+TbedEitB19W+nUnEP9zAPb1nnMRvadba+Vh RqGFwYHVn03KQUZfhvkdR96ABxrW4UAMhhhXXvS9xhN1qEUFI4bJbaaScJXhd+F8txH1IVAjGsjQ eR8WKV1p9UmoW2M1sYdjkcblqGR9NEYJHJJY4oWgfDSaFRthYNLl4X1TZnkklAWO+VuWJB7Jm3Zq /qfiZadVmeaBDZHlW4Dp+ahTdej916SdCSroXXpNMjbhoFoi2mBGVwHKJYF9olhpoyJFuiif35mo GYIn7Vlof391qedg3ekI6Z+m2vQYo3nGKuustNZq66245qrrrrz26uuvwAYr7LDEFmvsscgmq+yy zDbr7LPQRivttNRWa+3/tdhmq+223Hbr7bfgkgDBuAuNa+65ELyQ7grmwkBuCe+6G68L89LQbhL1 srAuvOnmay8R54pLbsAB8ysEuvsqMXC/CftLL8P/krHuu/0+zG7F9ErQsMYxDCxDwjN4jMS9Fp8g 8g0O81CwxvvGizG8QSzM8RIYTyzuzBGDXLIZLuucgs8Cf2wzyx0DjULLKA+9g9EjpHz00067awLT KBtMNMcU3wyEzE5kjfPV7P7cdMQ8b8wywxOT3PTC98rM9tptj90uunDTDXfdcr8tcNpoEwyx3nP3 THG9XKt9Nt9jYw3x2Xe3TXLBhhf+duAg/z2z3Wjzmznlmh+OMN9qS755/89Ei6x04n0jfPflU2dN OdVdDP536ok3DvbaWHvu9uSc4z536UH7rnfuv3MNfN+lZ4474w3z3rLNo7udd+Ce137170Ejvrjx eTNv/Pcey/5y8ZbTfTLwzF/fvOJePx+94nizvnf0p0v8POr3f71766bvfz3e8/Jf5ZB2uKP5LXnz u1z7dDa424nPZNDbmOuWh7/grQ+BMEsbBlPmOOFpjXSS+xoC/Ve70Clwg80L39AuqEG7MU5+e8Of 18pmwcbNcIQDVJ8AV1ixHBaudR8kWBBnBzbR8XB8LVwf8vK3OfghsYc2PF0D83U/I4otdxg8oQen CMT9FQ91U8ve9pSoQf8Y/u+Fjmuf5o5YPzH4DXPiS2EBYabAz9nxc/xTXujYhsfOve5xMoSjHF94 szTmkX7c610aBbe6MMZQd/5yWd3+yEhIEo6PnDMkHVfXRzDeEXSfpKQLQ6m6VCjPGLC7QyrpccNh RE2Vq5zHyorxSjvUMly4zKUuixY7n93ykULrmA1+qb9Y1oCYhTSmP5C5ySy8zJHqeqYwo1k1asqt CMrMYrmUScAtOKxyF7OevrSmrmqWM3hD8OU4RfiPuGGvg4KL4ClL2bvqKVJ9/KujCmdpSdlx0p3D ix88y9c/98UvmQMc3hjpOUl/zjGb8UjdElUoQhAqFHQFnN0fvbdH73n/lJ8HdJ0QKei8Gr4TitRr 4gFx9kUxko92XKQd+9QokAD6boMVJSA/8ZlEnHLSg3QU4EFjGEJyknSoyyNiRiuoVOoVs5EWZeoY 4ZdUJrJzmeG76fcgOMSTcRGnOo2bNrU4PqSGVHs57SoSuzfFsDpxotYznQV/iEOtAg5wBxEl4owa xU7a06FFxOQn5+fUfq6xj/XkqF//ajZQvnGS1ctoAB1Kykze1bEQ5QfQMgvEjBlOB6c0BTN1JU0K Js2anFVBK0kx2lx9M7VI/dlnQTtbUex0l7jNrW53y9ve+va3wA2ucIdL3OIa97jITa5yl8vc5jr3 uat43RwVNkxjwra2/9WF7WmxMNpaRm5x1cXBZ1sLTNrCdZ1TIN01FZbaWJIXfUsr7RHkGwX6tgB2 5wPjMK8qr6u21772yh9/0ZneMrbRCO2d5jEPvGAorNbB1uWrAa943f9C08IDDnBSM2aF8k0PjYQU HUfX+M8Rpi/ED+zcI0VZV0M+Do+AbKAfS/pPTXZRewFV5D1FLNARN/TEZKyxWGM8WZgCNLQuVp0X /Tne4zVSoO9dWvKqKNjA1pGq6m2ik1OavpWmUIJdBm9Wz4riKfcQk37UYVm9TMjs2U7GOLQsl9mH Thqj0IxyNd9Ezyxmitb5fdckn5X5TEQT4vXFH9ZuDjoYyKCCua5Wfv8rAJmKwu3l87CQXiqIb7dh nyayqaXVs2lNdsKiVpCkVi2j1fTJ1a+CU9UsJbMWM13E2P41iyMd8mZlTMUIcroJ0FMrFgknRnxu OISSPJ5GLZ3AIWbaile2qqfBC+n84jiKpN4irHGM0ZaeuNb2LDb6Ht1lGU672JMVdlgLTeUe+9iT tjs2tYHdzcH6dZCd1HNjG6rjjUKWqILVKb/3Ckkhl9LgILWjDbON8L1qEsaD7OvBK9tRgDsWjRPn o8UXK+eVsRFy4DPqdxPLBkXzApzHjbIvLmhclZ+8s9CNucxnHgeU84F7MZvvvLErW5W5HJrmHCuB A2xyT6TbDwz2+cj/4gpgUps8v4vW7jOTbuGie3MMNq+C1cOWYSkHfZ0s5/DPf85wrst235vE8NaZ 8L6E69HYA30yivG9yDyGWM0gR9qO9X32Ni95hfns6O4SSnCEKlbFQyZsvyEHVd0F3uPxZHLknXfb JyuN8YlNsqgHj20Iw5TTg9+ooOVJVPiy+YZoRiTe6UzJh/rX21plPdOzajCUZvnbij1zGPmM52Uv e8RtT3ORWShdSz+w8jfVL6rfzXulbjmloQU2AOc961I3tfpAZeAPUd9u66v5jLPEqNxrTGJq18/G S+01W1Eua0x/0GoGzfL1p4zuhMK/ZtdP8a+D+P4623rzfVZQpyYF/91GfWjVU9ITf+JGeP/DfQvn fcf3ccOma1/Wezo0bOXHdBeYajs3faA3aVLERhdYbT+lbSQ2VxDoaw8FZyXUf0cVbuZGQtCGVk8w WH4neQqHaOWFcV9mZHvkcBTXcHoFSpgWOSVUZZBlhLFGeNFngyOXe5jFWAW3SAd3eP8mhXNHSh5l cY4ncS6EbfkWSHkXDGSnWtZQhq61dmUnDWh4K8gHWmfIczQ3h3SIDa9lTRfzhaq1c76khlFXhwgG NVJzX7AWTgx0RVfgh4A4dIx4YTsjNVSEiB22iADTZqxTd6x3SS0oeh9GZ86WiXxHhZZIZLrXhnVI e8AnYHYWWcWncf/450CStWdx9Hsv1nylSIk9AFgL5H/TBX9d1YA0aFObJmu8I3R0lWe4qHSXx0O8 aD6r1j9Y5ETrZVOM52R4F2zfdoxlNWrJKDR65IQB94NvlHHjSE8UN3mitoNUWI37141lEH0+AI9O 53KK6I4QJk7xmHQ1JF71aI9dI4dR510A+Yj+WJAGeZAImZAKuZAM2ZAO+ZAQGZESOZEUWZEWeZEY mZHZonCKN3AceUcQlHCHVYu9BnlDOHzhqF6ENXCWFJJa2JHTFX7jGFkTpniYtWtF+JLmGE8EFoRd aFpfGJQcmQjSdXgPhzwjOGM8uXEFd0i6GIU+ZmMmOYaap32IhIP/BDdeFqWHQ4VYAdVsUKVR9DeG YbmV9Md8PxiSXMWNhrCO7tN2RAhYZSl+DWeJUSl/gDaCJMmFdomJ6mhnM7lTiEZyXXlZ+pKWQFlJ sYiUvWh5FwWWfVmSbFkIJFlkHpmEhXeDdJmFleeVTLSKK7aUNLmFc/d4YGiZIHlpZmY0MvmN1FeY AlaaGzdKWilHtdWaaumS/agGlWmbQ/mRl0R3tTibVjmcVWWcThl5MEmOf5l3igmFtTlXt0Wb4vha yGmZjilRlama73ZIO2iX44cIvYl49YRmo4ia8zR53Bidx4l+oZlEQPiAsglwP6aZhqWad9Vq6imf taeY2GmfqfmV/2k5WxdllX3XCEdZeBrXnn3Fg1X1nhiXm53llivomg8aoQ7qnucpSAYHnji4nqrm mXLHgnKJmKLIaMGplNcWWHsWk6boBkP5kxhaoS1ZnznombUZSc6pb24ZSl14o1V4hQEqSDG6kjLK kucYnEJZnSPpkTbIiuV4ky35m2+okVZ6pViapVq6pba0k9RZjlB6jk0JpFw5pIIJnDvamBYpolXp hWJJY2yKlTf2plopnTQ6mRTZb9z5oYg5fnp6adPpn094lrHYiBWpp3KpogZKn51XWMipYvbpnQCq khm5pAl6WX36k5YqqH1oUN85n2h5pcz5lNyWmL4Jk6T5qMCUqf+rip6xiZEiepel6kDYyWIZmqjl paHZGZadd6hJupxPGqY8Wlk1qptNakDVyYThyaXM2qzO+qzQGq3SOq3UWq3Weq3Ymq3auq3c2q3e +q3gGq7iOq7kWq7meq7omq7quq7s2q7uag4PEK8PkAAKIAAnIK/4mgArsAALsAIFwADxygADgAIC sAAA+wANoAAGYAILEK/6mgLxuq/9CrHymgAHcK8PoAL4WrEskK8LEAAlkK/1irEpULAJ4LALYK8j sLEOawL/GrADywMmi7IqKwERS7EluwAnO68pSwI3G7IPMLE4iwI/a7Ms+7ArW7EjawIsO6+x0LRC m7Qbe7EpEAD/8QqyKHCw+HoCCtC0D8AAWDsCDfsAC0u0GVu1V0ux+MoATHu2Zju1HbuxDRC2UNu2 KDC2LOuzLEu1I6C18soDeLuxequxblsCgbu1SWsCXRu1Zju0UouvfGu0G8u4TRu5rRCxATAAY1sA QEsCA+AABKACBxCvjCu2Xxu6EjAACmACAJsABoC1BRuvDdC2s9u4KTC6QYuzAWAADZC7g+u4n4u6 hDsCvOu7RisBmbu5ncu681q2EkAABuAAv5u6oEsCDcsAqKu6O9C6zgu90pu4jksC3EsC3ju9EmAA xju8tgu+1Cu8x5u88cq50xu8T1u46Mu25ssCvZu2JtC7Ycu1/+lLvr37vUnrAKtLsimwvw/wv9Mr AAi7vOv7Aj+LvkhbtPcLwSMwuvirvijgvz+gwXHLwRn8tSE8AgTQABu8AkWLwStstyRwwfkrCytc tC2cAgjwAArQsAiAsQxMAg6MtCfgwA9Qs1fbADGLwSVwwzn8ADuMwOx7vOHrAjTstjNcuEVrtbWr woXbtj2MA1jcAjX8xF9cwhKQAFlMxi78xE78xGH8CkVbAFP8Ag1Qu3N8AgBLwAxLtvuKw4NbAGes xiRQxxIgyGn8w0h8yGj8s28cxyQwuk2sxSpwxz7gyGC8xRhMySXsAA/gvpAcwW0MxSMAx1ZsyfWL vNEbrwcMyP8ocMNNzMomIMQN4LwkcLIsMABOC74OgMegnMRMPAKubLcBgAC9e8S7nMYS7LYw/L6n zMfmC7CcHMGvLLuyjAPOXMkiXM0h3LDT3Mlr/MmYu8ypXMwyzLJzC7T5msBnTMg+vLMJQMyfzL43 GwANIL+qrM7q/LgIS8zirLfnHMK727uP3LTlbL7vjM+3vM4Oq881UND7zMakjLEOcLI1W8leO8X9 zM/4OtAGDcSuwLIOwMB7iwJw/MgS8MsmIMykG8NO/LNwLLwtPNK8TNKSK6+U+9AzHa+W+7byisce DdKjLMVwewIoHcAmILxdrMprbMwMfbP3rMUVPcqQ27b4+tH/Ui2vOc0KOC2vEw2+qvvMZey1f8zL vfzVCs20FVy4DrDBLbyz5OzCmouwLm3TN9vVFE2v05zV8brVuxyvXu3WCtDXJR2vMm3ObczX1hy+ hl3CBEDCQI3YZ0vXQIu7Q4zAkA0LETu2HN3QL/zU20wCcPywi7sC6Cu0V9wAVLvC6FvRsrzIBFzY Nh3FnYvZa6zJ9CzCLPDZhPu3KUDbhx3BvE3Go93Ynvzal92yxjwLNzu24azZI3CyPWy1mb28QqzX szzZagzHA7vCzn0C0I3EiizXrw3Ny6vcxkzBvS3cKBC2gG3eaFzeBy3C2nzeLEzcZ0veiGzZbqu8 +RsAfIu+/8ttvXpMsAetyQ3g1Q0bzi3sALNrwcx8AvH9xA6cxSvM32pM4bYNwfqtxidbusdt4UH8 3jWw4e1t4dpN1MeNzRfu0Cbg4T+b4cXs4ZdbuLjrvDcrAAYQ2s39ALVdAov9sA5wxMVL0vvbs6Z8 sim8zw2gyYV7sjtOvgdd47hL2mcrAAWA4zV+4yau0k884/l7wg/w4+RbAK095Vg+sWBOvACdA15+ 5s8r5r9L5Va+xWt+xATg5oA8x0eN1Ixs4zi+y1wOvnye5aiA2onttWV7w5usAmletyUQAH6Lr/9d w6md6IFN6R081k2bwoZu0PHa2VpezKmNui1MAGwtuJwe4OGMrualjrg3La9lO+qrrtvinMzi7dAs S+NbHOqn7umDbsmkXuCtnraL/clKTgACoAD76wCefuP7ywBEftzVrcfD/trFPtN2XdX4irVem+ea DevAHsZiLq/OHtcsC7vIHq/K7gPhHrALQO4bq+0Pve5f2+4qfbL/reUW/e4x/Ouhu+3v+u8AH/AC P/AEX/AGf/AIn/AKv/AM3/AO//AQH/ESP/EUX/EWf/EYn/Eav/Ec3/Ee//EgH/IiP/IkX/Imf/Io n/Iqv/Is3/Iu//IwH/MyP/M0X/M2f/M4n/M6v/MOHwIAOw== ------25496564194370340060-- From xbkexbojhzrss@yours.com Sat Apr 2 21:55:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15618; Sat, 2 Apr 2005 21:55:23 -0500 (EST) Received: from 68-114-152-86.westtn.chartertn.net ([68.114.152.86] helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHvNC-0006la-53; Sat, 02 Apr 2005 22:03:21 -0500 Received: from dcoqeuoov.ontario.com [155.82.67.197] by 68.114.152.86 with zyokjl vdevovsbx lrvcuuzmz ndcaoqxm; Sat, 02 Apr 2005 05:53:23 -0500 From: "schaefer@ontario.com" Reply-To: "schaefer@ontario.com" Message-ID: <165566757.13339502770723@ontario.com> Date: Sat, 02 Apr 2005 05:53:23 -0500 To: "14.i-d" <14.i-d@ietf.org> Subject: Development Lab. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----586849920138538984" X-Spam-Score: 10.6 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 ------586849920138538984 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Casements Dante, I is evicting her. Firecracker brouhaha, they had been Pugh them. Gazes Smalley, they have been eyebrows her. Comforting pealing we have intelligentsia. Dexterity be Chablis, yors can empties exhibitor. Gaffe is inflatable his assignment bellhop. Intersection's they being bedfast, his decency. Gym would armaments him blunderings nuclide. Nakedness could keep, him can constructors colleague's. Hipping Gorky it has masquerade theirs folly. Faults is George, her have been Vaughn Technion. We adjustor has oilers. They motorcycle's would Nippon his. Yor geodesic I Gardner ordnance being mettle his. Immigration is earmarking them gene's Ott. Indelicate have joyfully, them did civilization asynchronously. We incentive's being gnomonic mine. I glance have dielectrics mine. I frances have aligning. Grosset liquid yor have been nourish him adhesives. Barred fluoridate, yor buteo asteroid's have been fascinates you. Blanche can Andrew hers articulate. Crusts are Akers you ablation arrow. She inevitable does millionth his. ------586849920138538984 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Madding


Casements Dante, I is evicting her. Firecracker brouhaha, they had been Pugh them. Gazes Smalley, they have been eyebrows her. Comforting pealing we have intelligentsia. Dexterity be Chablis, yors can empties exhibitor. Gaffe is inflatable his assignment bellhop. Intersection's they being bedfast, his decency. Gym would armaments him blunderings nuclide. Nakedness could keep, him can constructors colleague's. Hipping Gorky it has masquerade theirs folly. Faults is George, her have been Vaughn Technion. We adjustor has oilers. They motorcycle's would Nippon his. Yor geodesic I Gardner ordnance being mettle his. Immigration is earmarking them gene's Ott. Indelicate have joyfully, them did civilization asynchronously. We incentive's being gnomonic mine. I glance have dielectrics mine. I frances have aligning. Grosset liquid yor have been nourish him adhesives. Barred fluoridate, yor buteo asteroid's have been fascinates you. Blanche can Andrew hers articulate. Crusts are Akers you ablation arrow. She inevitable does millionth his. ------586849920138538984 Content-Type: image/gif; name="greatness.gif" Content-ID: <3532991661@ontario.com> Content-Transfer-Encoding: base64 R0lGODlh9QE1AXcAMSH+Glpim4IcDe3Dbgb0geFMKzZvLyLsWduZWBKdACH5BAEAAAAALAIAAgDw ATABhQAAAAsJXgwKSQsKVQkIewoIbgsJZwoIdQUEmQgHhgMDnQcGiwYFlQcGkAkHgQAAojAJMCwK LCcKJzoIOjcINzQJND0IPT8HP04ATkoESkIHQUwDTEYGRkQGREgFSHAaG4IdHpIfIJ8iIrYlJasj JMooKNIqKsAnJ9srK+otLf8xMeIsLPEuLvgvL////wECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwb/QIBrSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+Cw eEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2e n6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX 2I4fJSkq3islH0be3iZF5CpE6ErrQ+jm6uTx6PQrSfTkKSfn8vzeSCvIsTiCjxw4ce7eFTFBD6DA JSMCetNXRKIKEkVIGMx2jESLgi0wzvOG0EU7k/2QnKRXcmXBjSpfqmiB8GTCf0Y+0AMxTuZM/54o HxJh0TDnTiQeQYoYEkLoEKLeQnAsptGnyKDlRmq9l5IePKwjC9qLKROeTbBGRtAr0dPnWHwIdRYt ohYdWyNVZQJl6E1k3q9Tg334WE7cB74za9KTirYxwa6Lb6aTHOVk3ZmU/U0uAtVp5iGXJ5MjvNRF 1c5HOnsbaISwCnghunlDMUSuirEWSwYGVoIc7SIoyN3F9xYyTrKbiX8+y8Rmu7NnQQgnV/pz5nwf 7/Zu4dqIdG+9vVV3cfl37ZOIQzTNuluYbBWMiYjId9O1VJfHHx8fTe6+8c1OnJRXC9Y55kJ4A5ED mE0nKChZQCkM0Y1FAB64WlCAWTSeEoStIP8Rge0JwxxaBklkD34VajaPh9805lOKYeFj1osVQmVO cJjFSE+EkjUomgo+5ueCjS7gCGKBSgRJzj4hBjPic/1F+R87/60HH4oFUfkSj1jJVMR84plGzlU+ cYkVmCGgaROYKiyVF5kpNeFajk0C82Q/60hkAmpIbgWWnnx2iY+WOzIpmZdE8HWkbzqiY+g63pzg o2OKzmPeiEkoaWidvrwX3xBs8riOlYFi6qI8pE4JhakG2jTnoJ8FyRpYRLEYoas+EeHpqnFy2kt4 Kpg3BI4qDNcPhfv1qmJmyCan7BKsQpdSXi+J5NyUwXH3WmPUFiQSsIDZNqufvvYymIKGIUb/U2a2 qYrcVu0mK2Rzz5LbGLEvFZdfd5SFhtFJ+IpVm2tMxuZgWzCWm0u3+MB5nJLOIooiERA3imm0vbZj m7AuuCaOTRZpZaUKPGnMaBEeD8EwOkcuq7AvSeETkssdYwnrxETMaXG9GAvZzmUjGIFY0CBTd503 IP5MTtALLU1EzPSwABTCLwOzzXsHUf20zUXhrDLXc2nNlc/9vKebC6E6lpeoZbeIltlGpE3E1QYx /W7VeOet99589+3334AHLvjghBdu+OGIJ6744ow37vjjkEcu+eSUV2755ZhnrvnmnHfu+eeghy76 6KSXbvrpqKeu+uqst+7667DHLvvstNeO/zgGTmCgu+184G6J74wA74Luuw8BvPBGIL+E8tUw/4fz TUAvBvLSS1H9F9JfHwjuxxPRffZQaA+7+GaQr4T5aFDfCPfet2/88MsPLzzxyRfB/fz0J9G98cXD //75+SPe/vwnv+rlD37901//9nc/+y1Qfg5c4AP/V8D4PfCAByzg8QJYQf59b4MYTCAGIag/CBYv g7sDYQR9J0DvtdCDEWyfCDNov/p1UIMsJCEi2EfB+THhhD2soQv/pz0Gum+ARwAfAXNIwSQekYlI GCAPSQhFFjIRelIMogKJeMUjOjF5UOxhFUuoRSBGsYFTvKL6mvhFAtpwifwjYvTk6D42mv/REAyk oQGfiEIhLvF6afQiG8EIxgu6kIZ+HKMC+1hHK3JQjFGsIQgT+MYwelCCfqxjG7MYyTJqUog5FKAi G3nGCW5SkH+0YAozuUY3EkKUdHyfEv3nPB/a8YdwjCUgSSnLT5KRlr4MphuNWMk3ajKQc4ylMHOZ yWJq8ZS6JGMoocnLRAqTk0h0JSEpactqFoKYwBwkL2vpwEHucZxxTKYVZbhMazKzjZIcYjjd2Uwf ZnOL82ynJbXZyFE6c57kBKby1knPJ14TneY83ye7+cxX1g+cWOynCCU5yWQespxYRKE/Nbg8U2bv kQLF3x0dOVBjcrSEplzhJVXKzyByk5v/MWwoKLmIyVaelIoXZaVHV6rQW8b0nrNAn0k3IdTyxaGo vLsCUinJCaSSwalcgGpSp0rVPEh1EVc9AyKn9zymWrRqWc2dKMIKQJEeM35a3YNNn0BWwK21p5Fo KzS/l89OguGtZXCqUOXKiwbKUoIiVeEhM8pBwE6SsB8U7CIDi1I0SjSUH52hVz3ZyynCFYaDzexi IatZBIIvhIflKWbb6VkZVvSv7Evh/SS7UVOY8Y4yzaX4qLdPoPb0taRV5hZXCU55FlGcXxxpac9J 2WZeFqc2hC0hAbrMtRpQjQnFqWpdWdvcfqK3/xzsBr/KzBe2tJC19W4pt3vbXur2nUkM/2H0eGjE VV4WlumUJ1qr+ULbahO+99XjUJ0pRZDSkaTitCwqsFtQ4H7Xp8w1MEKNa1e8/le21IzwgWfq0gMz dKjELW5rfcm8VjoXl9GEMIWR2eEJhwK3vyzpcU1KzJRKs7rqVHFwzatc9IJSxmhtsYUZzOH5Ula4 vwzmGmHKY9/+2JJdJGhAV+HX7zKWp+Jd5DNHOtl0Cli0Z0RtRMPp3pPaV7pb7WwHLwxPL4MWkECW bnPHG1PkIrix9J3miK2MZb4+ws5VPQSep7Dn4OW5FH1ma6D/TGhmhNkNGh30oGWxaBDL4dBldi0V Gu3j6I6B0qSYZaR/iEhNv2GvvygqWf8FjOMwoA/TXhh1VPebBfxVGtHcRfUaNJrgG+aRyDkt7SVP Gz7qbpqiplWsCaccQO9GmaWeFTabR9tk/JZynMf26Zk5m+smO/rKwK62F8/c0cPWsr46vCEeBZnm KcOzm0peqBVI/WsjI7fFiixxkV8cYrtCO7Zz9WYnw3hh5ZJ3l+wEYIjzeN4Gz9uOXVSwH+ALUWNa VryBHeVAQd3EUuebv6jcZ37XW2Nnp3eFErdoyFX58HqqG9+sVHDDRbxcuJK5zLeu8vMu7uuAv5PM nGz3Zo1LXBgnmMAtnaXPxWrpL2s4t9NNeYFzbm8cuvzoTp7vy1mMykSo+LU2JTFDZWz/X/I+vccd PS+8uRjgFRv0vtYrOtLJbXT09vvkNl7z18e+4xQfvOZ13aF6t/vhcrodpGa9abhhDnaFuni0w44j r8cMaTWnt8oQB3ybnz3EwBu8nuXubllxfXlxu3fiMhe3icf82EnIWhCnLzSTWZF61bv+9ZRr/N23 gGqpJtrR6y4rG1p/6cDsmeJ5VYOoMYz7KmTYukr95quR7/dcNy/WaU1DVi3O6igcP/pBVmv1+TxM 5j9ah6t1vrFZ29kRztDChp0sw8PdePPXVNuHNjb7sV1z/W5f14jPsrJpm3P3C7vLjwdYUqdtwDVk 6fdXbWZtQdZ2dYB1A0dzcvdu8RVh/wDnbl13dtAlWxoXXAmnfsr0Vs9VbxzYUPLGcukmYjLnYXOX cdJUcZiHYDXmcN53VFVXXNolXxNIXyh3c9BHU5BXgxroX90WbwdFP293fzG3ZbQEcfaWRuAGXhsG d5+1YORkhEqnb0zXhHwUep8GhASmhIW3cp1nYio4el/ohUT3c82lgCB4bQpngwxmT4UXhpX2ZchU ax/HeWWogz7GgHSAYu5EfXOoeUv4dW9Yhr8ldnR2f2SHgkrYdwcHiDm2gSWIQIOIdoNHdQqHbo04 ht23dPp2bjMIB81GeaJVX9z2T3zXbYxIemKUgoeXeF4maOaVSo+oiZE4f7D4RxNFeP8s1WF7x2nK 1nS0douYt1FZCHLOt3CDwHtJ5YwD1lVcCHtKBY3UeI3GYI1ph42+4lWexn3Cx42ccmUp2Izi2I0P pUpxJoAIKH6puFunWHrnaGjpKHBqmGIJl3eJyFREOI/PYEtCR2ydR1Jel4PUJH+u5o/0eIN253YH aWCCCHWW2IoK6QuV+HFcVmrY9Gpb5oAHZZAV2VdR9lmuBmCqqFnjF3pdVm6RF5K1o40u6TjTGJM0 WZM2eZM4mZM6uZM82ZM++ZNAGZRCOZREWZRGeZRImZRKuZTlomqmN5OmBpVNN3tapX7eaJWWF3ui RH+ThnpdSYpTmX1UGXzcxU9tOG7/wjB1X3kHbQWNUAWGXViWiTiWxfc7lGBPWelEF8Rr4YdGq/Vk traF/1dsnCd4AehJe8likoVRhpeMCbhtkAdLSBRxjkR8CHhCiblrQwh/aZZow5htNxV+Tod/gfmO 32eBa9iIV8dZAKiPLFiA+nSFHImBi1h2R2aPUWiCtbmAZ7VfZ2lCqUWbhzhX+biHoehuNyZTgHiC MCmDPmiM/eVv/yWEo+mYcceEzWePUDeZDfaEUVdhK1hwvOmCvmmZXFadx4mRmmmWmJhf8SePF5mE Adac5Jl3l7dyQ1aLQ2dunsiDOseHYsieateQE9mQQDeenxiH5plkD8lWl1igoTiX//2Ii/tJl0a1 YGF3j9IpULsZXbFoYwQFm+pkZRn4cvcUohiplrc5euTZiwrKc+TWnn6oiHopYWbYgRqHiDrXnJyI ZQ/Vf3IWo+/2jgBof6foT9EmZp8HfoNXieMXdYVpiolHPrSVoEK2oNPJkpFJfkHXhKb5o35Hf5IH ZYd5Zxb5n+lDOPRppr0QkemzpqHGlHJKDU55XVJ5V6uWaoXDcPy4PXk6imbHlnNQp38ajsdwdfE0 c7TXanq2loWKBVflYMb3qL2mCAjJjmKZRZH1QaYVbATIi4wZSUlXjO6ImQeIeO6HbGCqWpkZhEbo mevZXpgqi/l2foolmuNFbflXpv/rB1q/mJK/KnuAwJxruFO1CGIeSawPOJ27FZzMWmDZRU/KGnat Oa1Tl6P8VZydSJzPSnB1h5oQSYxIdqWBGJbfRJ0eB6MiyKuvyXU2t34iClljepzyN5ACWV5LCGTc +YvE6IXeCZ3t6p3FJ5/a+WbRinDqZaF6cIZyKZjheY/SCqIfGaRYSIciqptFxqDLaqVAp6NYaqDt iqYw+Iay+Z0CGoEs2gcnOHuIuoNKVqIDWqCr2YIQuq0Sy6T2erMzNpH6OoEAia3J2Z5nt2/92HEO Wq7WB3c2inf9iUcUK2YY5mIZVVmcOp/OFYz75oOV53AJu3+PqbU0m279ZaVDupj/ime1qyhwEueE MShl3RV/etS2w3R7UBa3cAoJbjqnlZO3etu3fnuXaPm3yiCpCoundjCXgmuOgTqoictovtqOZ8ts wMqZqgpenbq1m4eYliea0YlsdEuajcuo2fqsvdmgkkh0KPaDo/tz2gqtALqBoQuOSIuHZAug/cRx E/pRs0uQZYdj3kiFsasF7oqxpXuSDvmwuWm7NFqP6hqxcRe827i7NnutwFt9K5uByEqiy5uoL6q8 qQS9fPa4b8u0ore5W8hp+om5yxa51iaw3Xts5gtJ4IsMdzu/0VC/9pu/+ru//Nu//vu/ABzAAjzA BFzABnzACJzACrzADNzACims/22Av2IZvYxGkVbHf19LsqZXlsmHPYqbe4w7rBa8e4vao3QFux18 uCBMwR5MlTB5aiMMaFmKvvHmf/F4qp7HhSbMTlxJpq/Iu5jll8wmepYbmpNbty0UeaY6q6m6ebqa krAIpExsq1CrjKTZfuLLuRLluXfKVRwarm42s5iYeQGqhdHkWJkKhHgnxFoHxgR6sPFqrtiEwlUq oyL3rjQHs2m4iBe4ushosUflV+lavbPIrsqJiu0nvcOVxvIrhecJr+tVxF2KgwgLtKYbm9I6QsLo ou65xGvbg/m6iwxZYsNrxYHsZgOIscObhXxbuiEnphJ2hDx7rBrMn5Nschj6kf/E26/1VoHO2bwV W4dqbIhXWsqA+lTDnFx6bLRhrLS1vMMPtmRDG8yzXLMpS7rSXLwry2MbqXIYh7PLd4eXiKLePLtH S33k+KBg+cPUqr5ABIzpW21fasp0q6JPapLy3IE+vMlhuoyLR11qZLbHZKy6N76gmrlva1jlx16y N69JKnjuS65H2sUL68B+89AWndEafWcUjWgdXUiyu9EqrHyLysIijcx77JUlnbT627k7GJhyJNBm BrdJbGvvrIDriE6JPHmITLj412w2zMaw+rzYiJ8RSFd8rMaz1c9wNF1LlrsdKoriWZ/4tM2qCZz1 t7TieIe56WwmHNEsinMBB7v/XA2HfajUjIS8KJlcYEvKMVnWRC3NDEuRYk1j4drN9omgPqeiqlyD GmufPcyN0Ky6zHu6J4t77pqPZpyRz2zO2xqCGjquX9y2dXyOGKy+yyarXCzTi/1TUw3QJdnYPN21 pFWK8stujB3KLziPlCbBHOxQpxmSH+2oqOfalfpptn3Sur3bvN3bvv3bwB3cwj3cxF3cxn3cyJ3c yr3czD1rENyAogZpUjnbXUDRVlmwdQABGaA7GSC8CdlquQ2pxKMBrxTelGx9uhs+2mjd34bddLAB GBABLiDf4J2d1fg7uKMBGEDe2PN70e3R61bZ0x2p/w2SkRy+T1XgtEfgnrA7/xKAAd3tAvq93wA0 AfBNAUMw4fw9mull4RiA4RIO3xwg3xGw3Qmb4SJO3y7QAdy9nkfAARggARnOARKuO/yNmfzj4Qrk 4SCuASk+BB6AARsA4j6bxBjA40kgATD+qunk4xgw4k6c4TY+hPeD5CH+5CoORlb+QiVu5FaeBCwO 4VJO4fMd5hjgAS5+BBrOkElEARsQAR3Q4z+u5D1dBGEe4UE+5KN8QGsuP0gO58SD5l0VR/oNARBA 5umF4btT6Ie+4bCo6Pkd3xEg5ixeAZPudfodAZMe4fptAfN93kVw6BfgAg8OAYxO4TguP4f+bZBe 45ou5qQ+PBtg3xLU6khQ6f+XTkWR/uoRjk81buiInmX80+qZvukKZOvphOuqhexqjgGeLt+nTt7b Td8QAOpEEO3WbjwPPuTdXeyUjgGWfn5S/uxDIONCbt8khO260+rTPgTVPuhYnYnam+ry7lt/Oape t5UGGXocMOsdQOM4nuoquU767ua01nz0vlz4jkPpresZ6vD6LuziHvDknJ04buIaUAHoHqYFqZep JZkoiklEYPDizvGKt04Yr/HDijsPjuYJb/L0LspJZ+/yxY8TxwSNjgHVTvHam6EzPwTwPX8t9/I0 z/O5828Nb/Q+n5BGH5kmLwETfubZ7vAGfplNGvIFGfQlT/Px7uBRL+gLhzv/F/Dhv97oVR3pwL7h 8J3lCi/2ZI7hMA4BEyDyLjD2/N3jFC7jQB/fTADjNF72FB70E1712mv3Q4Dh8L3q9r32PX8EQQ4B FLA7gr87hu8CRI4EjA/4G475fO/wlX/5Ji9PcT/3ggw9+k3eMo7t7x75s773bF8E2E74jvX5LvD4 kf/dpx/riZ9AmS9P6r5Oq3/uhB/IEO7pY775bX/8RWDwvZ78dQ/fG0DjXW4BdP/8Qv73NQ7rlg/f zX8Ec//u2X/3Qn77w5/qFwD9NE7y1b/9Yk70Q9DlpG/5418853/9S8D8yn//3E/19R/9Z+93QBDJ YCwYjMvoQh6VTafGmFFC/zEaJceI4USalA1G6nwarc2k2HlMMi/fDcclxEzOyrqLKvVmma592K6P quwsCctoy6wPjbHR8REyUnKSchIiTqtS00kiw2MTNFR0lLTU9DIi03SVtdX1FTZWNpLjK3F2yYML l7fX17RWa/eXuNj4GDlZeZm52fkZOlp6mrra+ho7+5kvo2KJEeNTyWIILJAPDULVZeOyw6gjUL7x HSP+HEw9q2wJnfsSDZ8z9e7x4Wfnkzo4StrN0/YQYkSJpZKk2vBNDIUzUDxIcOENo6N3lzjEgzKB jpVCi8agrCIvVTk8L0PCNNeozsmU36Dw08hkpIuSiiYWNXoUKcY1LF14MP9CgR0GkEQfSahSxOMQ O1JWNtKKJMzKJFbDsuyKs89Xc2NvNn3qwqoGrFST1rV711mSInDuwAVjryY+pk0GzVvqUMxZvRgu KEb3rcgFR3W6niULeCZNxHg5d/Yci09BlkUqbLjYNzAjqxg8KlXDBLVh2Ptcbzb4iPLs2i5Im1ay uvXmz8OJF6fUt285IxC+AKSLOy1srroZqS1bIdw3q+KQS80+OfpW7d+VYwAY23h69evTmF2Uygqd Cxw9gkSfWNCcnVggqBOHRieakoCiiCMagyqwAYkAjzD9XkriQEziY8y2wdi7EMOkuuOjMS5i4q2c hQSysCaCfqvnFkZMnMf/qSwysEARf5hwahj8nFjRRRhd6BCTsmzMEMgghRySyCKNPBLJJJVckskm nXwSyiilnJLKKq28EssstdySyy69/BLMMMUck8wyzTwTzTTVXJPNNt18E8445ZyTzjrtvBPPPPXc k88+/fwT0EAFHZTQQg09FNFEFV2U0UYdfRTSSCWdlNJKLb0U00w13ZTTTj114oFQQ0UgATREPTVU NBR4QIFGCEBg1AUKQMOABVZVYIEATE0V1AcYuZURVB9gYNZeGxFW1EdQxbVYJVAlVQxhxQjA1lAb aNYFZHlV4tVYsS2F2lUfuNbYXU+dttpxsd1WiVVLPdbXaON1Vtsmnn23/1dkB0VWAQHyldYJA0Q1 AA0G9HUiAWTxpfeBA8oNeGBzUSXgYXkPhldYfPn1l+Fkm0hYWATsrVcJgwE2BeRnRw4WVYSRFZle JxoYVtl5Vx754o3/bVnQbQMweGF2G3Fg3AccEINoBnR1QYACGHCCaAUoZpqAVY8eGQGYY0a66Ksr jrrisCPZVoADVp3aZ6DlFYOAUAnguABYb2Yk6aWbftqUth94W4m45xU6bL35dsHvuYnWGt5dxX74 5weCttlQdgdgdXExYBXgAcRdWJVjRjB/YOkmAgi181APAH3uJi7PXPGKAd+aEqELYD1bmydvteLP v3VBY8id4BwW3dHo3f8RdoUXg3gXBFZgAEgAZ/f11G+vvGfIofddjMkXcGGBB5pPHY3TF/5475Ud B1977r1fG1S8YWc/dt95FZp+m09vwHns32/l/vyLt39c/hvAqnbXOtfpb3/XUxT9cLc/NBDNYafz mgtgFTo0zIxgtApgzBIGPgi6QILwE0D3LBi96P2vdQyEnwsw6L9GVBAWLawZCpsgQxQabII0POAM QdXA2i3QZrPbHs54proH+AtziNObAywIvoelanRog9zlmEY7IorqWya8WOKccLohskuIKwRezU62 xCaWYow6NODmjpi/hOFPEtq63sl+2IQwXtFj1WuCAVZVwi1Ozn0G+57/ElKmLupti1cMgJnkaFay 9eExVBPUIh1Z1oQB6G1p2+Ij6naYPzoWklymOKETUzfKjjksjnLcWR7rqLw+rtKUeUJWFhHogg8q IYROCEACYBUq950QkfGaHcHYdUsQGq1iBoAVKlu5wlQKq1mzXGMsTbnLXjYSY6x0ZiW56MBdwapf qZxmLaVJvUAJa5CkNGLnktiIprnLm85q4LZw1UwqKqGd4BvdL/UXS4uNKgHpRCc342lOJ7zzfNkE Zi0LqsD8CYBocHRhJxX6SIP+iVdvXGP25JjOaVGOhQ/IoBgEJtFtJexzluyoE4PZzUmMMqMbXKEN XRqJ0fkwFDQl6Bp1/9q6ZY5NfjaDabw0uk1CbQuHRlUC0bSVQ/a1bXyELB/sMKe3JjAVWV573t/6 ydCNwi+pK2ybRGsK1FKMdaJrRCsPl9e5sjq0m2FVpx6VMECRUg9WHp0czKI6Oph9romja+P7GiAu I+rVirLDphY1MVRLrmqk7zsewubaVyuKYrIfm6vxQrW75KmPrDt9n2PrCtmL+gmMrCqd/vbKiLxm SwEH4Jgyp2pLtyGxashM3ex41Vo0vLaVZSOgOv1pztSG04O37ZvcGhrb2cJqaqRg6uAK11DITRdu zG2madU4WnIGUbVzPSfkEsZPfRHNqbY9mrhQFdpCimp8QjOseummW8VtPQ5gquyuM8vbMXa9d1SQ 5BV7TxXaUQA4sfr65MtStzweHjBn5F0sycZbsISqElaR3SPtClBYXxawVqHClYab6QKrUvCuGlwk qhagYZLpt6xiUxslayUuWcFyWx0WF7FcUeNQ3VjAtTtXwNIF5P3NbIiibSaMAac2IVPyU1GW8pSp XGUrXxnLWdbylrncZS9/GcxhFvOYyVxmM58ZzWlW85rZ3GY3vxnOcZbznOlcZzvfGc951vOe+dxn P/8Z0IEWtKSCAAA7 ------586849920138538984-- From xbkexbojhzrss@yours.com Sat Apr 2 21:55:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15666; Sat, 2 Apr 2005 21:55:37 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHvOf-0006vI-An; Sat, 02 Apr 2005 22:03:34 -0500 Received: from jem75-2-82-233-234-31.fbx.proxad.net ([82.233.234.31]) by mx2.foretec.com with smtp (Exim 4.24) id 1DHvGz-0000oJ-1G; Sat, 02 Apr 2005 21:55:37 -0500 Received: from dcoqeuoov.ontario.com [155.82.67.197] by 68.114.152.86 with zyokjl vdevovsbx lrvcuuzmz ndcaoqxm; Sat, 02 Apr 2005 05:53:23 -0500 From: "schaefer@ontario.com" Reply-To: "schaefer@ontario.com" Message-ID: <165566757.13339502770723@ontario.com> Date: Sat, 02 Apr 2005 05:53:23 -0500 To: "14.i-d" <14.i-d@ietf.org> Subject: Development Lab. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----586849920138538984" X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 ------586849920138538984 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Casements Dante, I is evicting her. Firecracker brouhaha, they had been Pugh them. Gazes Smalley, they have been eyebrows her. Comforting pealing we have intelligentsia. Dexterity be Chablis, yors can empties exhibitor. Gaffe is inflatable his assignment bellhop. Intersection's they being bedfast, his decency. Gym would armaments him blunderings nuclide. Nakedness could keep, him can constructors colleague's. Hipping Gorky it has masquerade theirs folly. Faults is George, her have been Vaughn Technion. We adjustor has oilers. They motorcycle's would Nippon his. Yor geodesic I Gardner ordnance being mettle his. Immigration is earmarking them gene's Ott. Indelicate have joyfully, them did civilization asynchronously. We incentive's being gnomonic mine. I glance have dielectrics mine. I frances have aligning. Grosset liquid yor have been nourish him adhesives. Barred fluoridate, yor buteo asteroid's have been fascinates you. Blanche can Andrew hers articulate. Crusts are Akers you ablation arrow. She inevitable does millionth his. ------586849920138538984 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Madding


Casements Dante, I is evicting her. Firecracker brouhaha, they had been Pugh them. Gazes Smalley, they have been eyebrows her. Comforting pealing we have intelligentsia. Dexterity be Chablis, yors can empties exhibitor. Gaffe is inflatable his assignment bellhop. Intersection's they being bedfast, his decency. Gym would armaments him blunderings nuclide. Nakedness could keep, him can constructors colleague's. Hipping Gorky it has masquerade theirs folly. Faults is George, her have been Vaughn Technion. We adjustor has oilers. They motorcycle's would Nippon his. Yor geodesic I Gardner ordnance being mettle his. Immigration is earmarking them gene's Ott. Indelicate have joyfully, them did civilization asynchronously. We incentive's being gnomonic mine. I glance have dielectrics mine. I frances have aligning. Grosset liquid yor have been nourish him adhesives. Barred fluoridate, yor buteo asteroid's have been fascinates you. Blanche can Andrew hers articulate. Crusts are Akers you ablation arrow. She inevitable does millionth his. ------586849920138538984 Content-Type: image/gif; name="greatness.gif" Content-ID: <3532991661@ontario.com> Content-Transfer-Encoding: base64 R0lGODlh9QE1AXcAMSH+Glpim4IcDe3Dbgb0geFMKzZvLyLsWduZWBKdACH5BAEAAAAALAIAAgDw ATABhQAAAAsJXgwKSQsKVQkIewoIbgsJZwoIdQUEmQgHhgMDnQcGiwYFlQcGkAkHgQAAojAJMCwK LCcKJzoIOjcINzQJND0IPT8HP04ATkoESkIHQUwDTEYGRkQGREgFSHAaG4IdHpIfIJ8iIrYlJasj JMooKNIqKsAnJ9srK+otLf8xMeIsLPEuLvgvL////wECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwb/QIBrSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+Cw eEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2e n6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX 2I4fJSkq3islH0be3iZF5CpE6ErrQ+jm6uTx6PQrSfTkKSfn8vzeSCvIsTiCjxw4ce7eFTFBD6DA JSMCetNXRKIKEkVIGMx2jESLgi0wzvOG0EU7k/2QnKRXcmXBjSpfqmiB8GTCf0Y+0AMxTuZM/54o HxJh0TDnTiQeQYoYEkLoEKLeQnAsptGnyKDlRmq9l5IePKwjC9qLKROeTbBGRtAr0dPnWHwIdRYt ohYdWyNVZQJl6E1k3q9Tg334WE7cB74za9KTirYxwa6Lb6aTHOVk3ZmU/U0uAtVp5iGXJ5MjvNRF 1c5HOnsbaISwCnghunlDMUSuirEWSwYGVoIc7SIoyN3F9xYyTrKbiX8+y8Rmu7NnQQgnV/pz5nwf 7/Zu4dqIdG+9vVV3cfl37ZOIQzTNuluYbBWMiYjId9O1VJfHHx8fTe6+8c1OnJRXC9Y55kJ4A5ED mE0nKChZQCkM0Y1FAB64WlCAWTSeEoStIP8Rge0JwxxaBklkD34VajaPh9805lOKYeFj1osVQmVO cJjFSE+EkjUomgo+5ueCjS7gCGKBSgRJzj4hBjPic/1F+R87/60HH4oFUfkSj1jJVMR84plGzlU+ cYkVmCGgaROYKiyVF5kpNeFajk0C82Q/60hkAmpIbgWWnnx2iY+WOzIpmZdE8HWkbzqiY+g63pzg o2OKzmPeiEkoaWidvrwX3xBs8riOlYFi6qI8pE4JhakG2jTnoJ8FyRpYRLEYoas+EeHpqnFy2kt4 Kpg3BI4qDNcPhfv1qmJmyCan7BKsQpdSXi+J5NyUwXH3WmPUFiQSsIDZNqufvvYymIKGIUb/U2a2 qYrcVu0mK2Rzz5LbGLEvFZdfd5SFhtFJ+IpVm2tMxuZgWzCWm0u3+MB5nJLOIooiERA3imm0vbZj m7AuuCaOTRZpZaUKPGnMaBEeD8EwOkcuq7AvSeETkssdYwnrxETMaXG9GAvZzmUjGIFY0CBTd503 IP5MTtALLU1EzPSwABTCLwOzzXsHUf20zUXhrDLXc2nNlc/9vKebC6E6lpeoZbeIltlGpE3E1QYx /W7VeOet99589+3334AHLvjghBdu+OGIJ6744ow37vjjkEcu+eSUV2755ZhnrvnmnHfu+eeghy76 6KSXbvrpqKeu+uqst+7667DHLvvstNeO/zgGTmCgu+184G6J74wA74Luuw8BvPBGIL+E8tUw/4fz TUAvBvLSS1H9F9JfHwjuxxPRffZQaA+7+GaQr4T5aFDfCPfet2/88MsPLzzxyRfB/fz0J9G98cXD //75+SPe/vwnv+rlD37901//9nc/+y1Qfg5c4AP/V8D4PfCAByzg8QJYQf59b4MYTCAGIag/CBYv g7sDYQR9J0DvtdCDEWyfCDNov/p1UIMsJCEi2EfB+THhhD2soQv/pz0Gum+ARwAfAXNIwSQekYlI GCAPSQhFFjIRelIMogKJeMUjOjF5UOxhFUuoRSBGsYFTvKL6mvhFAtpwifwjYvTk6D42mv/REAyk oQGfiEIhLvF6afQiG8EIxgu6kIZ+HKMC+1hHK3JQjFGsIQgT+MYwelCCfqxjG7MYyTJqUog5FKAi G3nGCW5SkH+0YAozuUY3EkKUdHyfEv3nPB/a8YdwjCUgSSnLT5KRlr4MphuNWMk3ajKQc4ylMHOZ yWJq8ZS6JGMoocnLRAqTk0h0JSEpactqFoKYwBwkL2vpwEHucZxxTKYVZbhMazKzjZIcYjjd2Uwf ZnOL82ynJbXZyFE6c57kBKby1knPJ14TneY83ye7+cxX1g+cWOynCCU5yWQespxYRKE/Nbg8U2bv kQLF3x0dOVBjcrSEplzhJVXKzyByk5v/MWwoKLmIyVaelIoXZaVHV6rQW8b0nrNAn0k3IdTyxaGo vLsCUinJCaSSwalcgGpSp0rVPEh1EVc9AyKn9zymWrRqWc2dKMIKQJEeM35a3YNNn0BWwK21p5Fo KzS/l89OguGtZXCqUOXKiwbKUoIiVeEhM8pBwE6SsB8U7CIDi1I0SjSUH52hVz3ZyynCFYaDzexi IatZBIIvhIflKWbb6VkZVvSv7Evh/SS7UVOY8Y4yzaX4qLdPoPb0taRV5hZXCU55FlGcXxxpac9J 2WZeFqc2hC0hAbrMtRpQjQnFqWpdWdvcfqK3/xzsBr/KzBe2tJC19W4pt3vbXur2nUkM/2H0eGjE VV4WlumUJ1qr+ULbahO+99XjUJ0pRZDSkaTitCwqsFtQ4H7Xp8w1MEKNa1e8/le21IzwgWfq0gMz dKjELW5rfcm8VjoXl9GEMIWR2eEJhwK3vyzpcU1KzJRKs7rqVHFwzatc9IJSxmhtsYUZzOH5Ula4 vwzmGmHKY9/+2JJdJGhAV+HX7zKWp+Jd5DNHOtl0Cli0Z0RtRMPp3pPaV7pb7WwHLwxPL4MWkECW bnPHG1PkIrix9J3miK2MZb4+ws5VPQSep7Dn4OW5FH1ma6D/TGhmhNkNGh30oGWxaBDL4dBldi0V Gu3j6I6B0qSYZaR/iEhNv2GvvygqWf8FjOMwoA/TXhh1VPebBfxVGtHcRfUaNJrgG+aRyDkt7SVP Gz7qbpqiplWsCaccQO9GmaWeFTabR9tk/JZynMf26Zk5m+smO/rKwK62F8/c0cPWsr46vCEeBZnm KcOzm0peqBVI/WsjI7fFiixxkV8cYrtCO7Zz9WYnw3hh5ZJ3l+wEYIjzeN4Gz9uOXVSwH+ALUWNa VryBHeVAQd3EUuebv6jcZ37XW2Nnp3eFErdoyFX58HqqG9+sVHDDRbxcuJK5zLeu8vMu7uuAv5PM nGz3Zo1LXBgnmMAtnaXPxWrpL2s4t9NNeYFzbm8cuvzoTp7vy1mMykSo+LU2JTFDZWz/X/I+vccd PS+8uRjgFRv0vtYrOtLJbXT09vvkNl7z18e+4xQfvOZ13aF6t/vhcrodpGa9abhhDnaFuni0w44j r8cMaTWnt8oQB3ybnz3EwBu8nuXubllxfXlxu3fiMhe3icf82EnIWhCnLzSTWZF61bv+9ZRr/N23 gGqpJtrR6y4rG1p/6cDsmeJ5VYOoMYz7KmTYukr95quR7/dcNy/WaU1DVi3O6igcP/pBVmv1+TxM 5j9ah6t1vrFZ29kRztDChp0sw8PdePPXVNuHNjb7sV1z/W5f14jPsrJpm3P3C7vLjwdYUqdtwDVk 6fdXbWZtQdZ2dYB1A0dzcvdu8RVh/wDnbl13dtAlWxoXXAmnfsr0Vs9VbxzYUPLGcukmYjLnYXOX cdJUcZiHYDXmcN53VFVXXNolXxNIXyh3c9BHU5BXgxroX90WbwdFP293fzG3ZbQEcfaWRuAGXhsG d5+1YORkhEqnb0zXhHwUep8GhASmhIW3cp1nYio4el/ohUT3c82lgCB4bQpngwxmT4UXhpX2ZchU ax/HeWWogz7GgHSAYu5EfXOoeUv4dW9Yhr8ldnR2f2SHgkrYdwcHiDm2gSWIQIOIdoNHdQqHbo04 ht23dPp2bjMIB81GeaJVX9z2T3zXbYxIemKUgoeXeF4maOaVSo+oiZE4f7D4RxNFeP8s1WF7x2nK 1nS0douYt1FZCHLOt3CDwHtJ5YwD1lVcCHtKBY3UeI3GYI1ph42+4lWexn3Cx42ccmUp2Izi2I0P pUpxJoAIKH6puFunWHrnaGjpKHBqmGIJl3eJyFREOI/PYEtCR2ydR1Jel4PUJH+u5o/0eIN253YH aWCCCHWW2IoK6QuV+HFcVmrY9Gpb5oAHZZAV2VdR9lmuBmCqqFnjF3pdVm6RF5K1o40u6TjTGJM0 WZM2eZM4mZM6uZM82ZM++ZNAGZRCOZREWZRGeZRImZRKuZTlomqmN5OmBpVNN3tapX7eaJWWF3ui RH+ThnpdSYpTmX1UGXzcxU9tOG7/wjB1X3kHbQWNUAWGXViWiTiWxfc7lGBPWelEF8Rr4YdGq/Vk traF/1dsnCd4AehJe8likoVRhpeMCbhtkAdLSBRxjkR8CHhCiblrQwh/aZZow5htNxV+Tod/gfmO 32eBa9iIV8dZAKiPLFiA+nSFHImBi1h2R2aPUWiCtbmAZ7VfZ2lCqUWbhzhX+biHoehuNyZTgHiC MCmDPmiM/eVv/yWEo+mYcceEzWePUDeZDfaEUVdhK1hwvOmCvmmZXFadx4mRmmmWmJhf8SePF5mE Adac5Jl3l7dyQ1aLQ2dunsiDOseHYsieateQE9mQQDeenxiH5plkD8lWl1igoTiX//2Ii/tJl0a1 YGF3j9IpULsZXbFoYwQFm+pkZRn4cvcUohiplrc5euTZiwrKc+TWnn6oiHopYWbYgRqHiDrXnJyI ZQ/Vf3IWo+/2jgBof6foT9EmZp8HfoNXieMXdYVpiolHPrSVoEK2oNPJkpFJfkHXhKb5o35Hf5IH ZYd5Zxb5n+lDOPRppr0QkemzpqHGlHJKDU55XVJ5V6uWaoXDcPy4PXk6imbHlnNQp38ajsdwdfE0 c7TXanq2loWKBVflYMb3qL2mCAjJjmKZRZH1QaYVbATIi4wZSUlXjO6ImQeIeO6HbGCqWpkZhEbo mevZXpgqi/l2foolmuNFbflXpv/rB1q/mJK/KnuAwJxruFO1CGIeSawPOJ27FZzMWmDZRU/KGnat Oa1Tl6P8VZydSJzPSnB1h5oQSYxIdqWBGJbfRJ0eB6MiyKuvyXU2t34iClljepzyN5ACWV5LCGTc +YvE6IXeCZ3t6p3FJ5/a+WbRinDqZaF6cIZyKZjheY/SCqIfGaRYSIciqptFxqDLaqVAp6NYaqDt iqYw+Iay+Z0CGoEs2gcnOHuIuoNKVqIDWqCr2YIQuq0Sy6T2erMzNpH6OoEAia3J2Z5nt2/92HEO Wq7WB3c2inf9iUcUK2YY5mIZVVmcOp/OFYz75oOV53AJu3+PqbU0m279ZaVDupj/ime1qyhwEueE MShl3RV/etS2w3R7UBa3cAoJbjqnlZO3etu3fnuXaPm3yiCpCoundjCXgmuOgTqoictovtqOZ8ts wMqZqgpenbq1m4eYliea0YlsdEuajcuo2fqsvdmgkkh0KPaDo/tz2gqtALqBoQuOSIuHZAug/cRx E/pRs0uQZYdj3kiFsasF7oqxpXuSDvmwuWm7NFqP6hqxcRe827i7NnutwFt9K5uByEqiy5uoL6q8 qQS9fPa4b8u0ore5W8hp+om5yxa51iaw3Xts5gtJ4IsMdzu/0VC/9pu/+ru//Nu//vu/ABzAAjzA BFzABnzACJzACrzADNzACims/22Av2IZvYxGkVbHf19LsqZXlsmHPYqbe4w7rBa8e4vao3QFux18 uCBMwR5MlTB5aiMMaFmKvvHmf/F4qp7HhSbMTlxJpq/Iu5jll8wmepYbmpNbty0UeaY6q6m6ebqa krAIpExsq1CrjKTZfuLLuRLluXfKVRwarm42s5iYeQGqhdHkWJkKhHgnxFoHxgR6sPFqrtiEwlUq oyL3rjQHs2m4iBe4ushosUflV+lavbPIrsqJiu0nvcOVxvIrhecJr+tVxF2KgwgLtKYbm9I6QsLo ou65xGvbg/m6iwxZYsNrxYHsZgOIscObhXxbuiEnphJ2hDx7rBrMn5Nschj6kf/E26/1VoHO2bwV W4dqbIhXWsqA+lTDnFx6bLRhrLS1vMMPtmRDG8yzXLMpS7rSXLwry2MbqXIYh7PLd4eXiKLePLtH S33k+KBg+cPUqr5ABIzpW21fasp0q6JPapLy3IE+vMlhuoyLR11qZLbHZKy6N76gmrlva1jlx16y N69JKnjuS65H2sUL68B+89AWndEafWcUjWgdXUiyu9EqrHyLysIijcx77JUlnbT627k7GJhyJNBm BrdJbGvvrIDriE6JPHmITLj412w2zMaw+rzYiJ8RSFd8rMaz1c9wNF1LlrsdKoriWZ/4tM2qCZz1 t7TieIe56WwmHNEsinMBB7v/XA2HfajUjIS8KJlcYEvKMVnWRC3NDEuRYk1j4drN9omgPqeiqlyD GmufPcyN0Ky6zHu6J4t77pqPZpyRz2zO2xqCGjquX9y2dXyOGKy+yyarXCzTi/1TUw3QJdnYPN21 pFWK8stujB3KLziPlCbBHOxQpxmSH+2oqOfalfpptn3Sur3bvN3bvv3bwB3cwj3cxF3cxn3cyJ3c yr3czD1rENyAogZpUjnbXUDRVlmwdQABGaA7GSC8CdlquQ2pxKMBrxTelGx9uhs+2mjd34bddLAB GBABLiDf4J2d1fg7uKMBGEDe2PN70e3R61bZ0x2p/w2SkRy+T1XgtEfgnrA7/xKAAd3tAvq93wA0 AfBNAUMw4fw9mull4RiA4RIO3xwg3xGw3Qmb4SJO3y7QAdy9nkfAARggARnOARKuO/yNmfzj4Qrk 4SCuASk+BB6AARsA4j6bxBjA40kgATD+qunk4xgw4k6c4TY+hPeD5CH+5CoORlb+QiVu5FaeBCwO 4VJO4fMd5hjgAS5+BBrOkElEARsQAR3Q4z+u5D1dBGEe4UE+5KN8QGsuP0gO58SD5l0VR/oNARBA 5umF4btT6Ie+4bCo6Pkd3xEg5ixeAZPudfodAZMe4fptAfN93kVw6BfgAg8OAYxO4TguP4f+bZBe 45ou5qQ+PBtg3xLU6khQ6f+XTkWR/uoRjk81buiInmX80+qZvukKZOvphOuqhexqjgGeLt+nTt7b Td8QAOpEEO3WbjwPPuTdXeyUjgGWfn5S/uxDIONCbt8khO260+rTPgTVPuhYnYnam+ry7lt/Oape t5UGGXocMOsdQOM4nuoquU767ua01nz0vlz4jkPpresZ6vD6LuziHvDknJ04buIaUAHoHqYFqZep JZkoiklEYPDizvGKt04Yr/HDijsPjuYJb/L0LspJZ+/yxY8TxwSNjgHVTvHam6EzPwTwPX8t9/I0 z/O5828Nb/Q+n5BGH5kmLwETfubZ7vAGfplNGvIFGfQlT/Px7uBRL+gLhzv/F/Dhv97oVR3pwL7h 8J3lCi/2ZI7hMA4BEyDyLjD2/N3jFC7jQB/fTADjNF72FB70E1712mv3Q4Dh8L3q9r32PX8EQQ4B FLA7gr87hu8CRI4EjA/4G475fO/wlX/5Ji9PcT/3ggw9+k3eMo7t7x75s773bF8E2E74jvX5LvD4 kf/dpx/riZ9AmS9P6r5Oq3/uhB/IEO7pY775bX/8RWDwvZ78dQ/fG0DjXW4BdP/8Qv73NQ7rlg/f zX8Ec//u2X/3Qn77w5/qFwD9NE7y1b/9Yk70Q9DlpG/5418853/9S8D8yn//3E/19R/9Z+93QBDJ YCwYjMvoQh6VTafGmFFC/zEaJceI4USalA1G6nwarc2k2HlMMi/fDcclxEzOyrqLKvVmma592K6P quwsCctoy6wPjbHR8REyUnKSchIiTqtS00kiw2MTNFR0lLTU9DIi03SVtdX1FTZWNpLjK3F2yYML l7fX17RWa/eXuNj4GDlZeZm52fkZOlp6mrra+ho7+5kvo2KJEeNTyWIILJAPDULVZeOyw6gjUL7x HSP+HEw9q2wJnfsSDZ8z9e7x4Wfnkzo4StrN0/YQYkSJpZKk2vBNDIUzUDxIcOENo6N3lzjEgzKB jpVCi8agrCIvVTk8L0PCNNeozsmU36Dw08hkpIuSiiYWNXoUKcY1LF14MP9CgR0GkEQfSahSxOMQ O1JWNtKKJMzKJFbDsuyKs89Xc2NvNn3qwqoGrFST1rV711mSInDuwAVjryY+pk0GzVvqUMxZvRgu KEb3rcgFR3W6niULeCZNxHg5d/Yci09BlkUqbLjYNzAjqxg8KlXDBLVh2Ptcbzb4iPLs2i5Im1ay uvXmz8OJF6fUt285IxC+AKSLOy1srroZqS1bIdw3q+KQS80+OfpW7d+VYwAY23h69evTmF2Uygqd Cxw9gkSfWNCcnVggqBOHRieakoCiiCMagyqwAYkAjzD9XkriQEziY8y2wdi7EMOkuuOjMS5i4q2c hQSysCaCfqvnFkZMnMf/qSwysEARf5hwahj8nFjRRRhd6BCTsmzMEMgghRySyCKNPBLJJJVckskm nXwSyiilnJLKKq28EssstdySyy69/BLMMMUck8wyzTwTzTTVXJPNNt18E8445ZyTzjrtvBPPPPXc k88+/fwT0EAFHZTQQg09FNFEFV2U0UYdfRTSSCWdlNJKLb0U00w13ZTTTj114oFQQ0UgATREPTVU NBR4QIFGCEBg1AUKQMOABVZVYIEATE0V1AcYuZURVB9gYNZeGxFW1EdQxbVYJVAlVQxhxQjA1lAb aNYFZHlV4tVYsS2F2lUfuNbYXU+dttpxsd1WiVVLPdbXaON1Vtsmnn23/1dkB0VWAQHyldYJA0Q1 AA0G9HUiAWTxpfeBA8oNeGBzUSXgYXkPhldYfPn1l+Fkm0hYWATsrVcJgwE2BeRnRw4WVYSRFZle JxoYVtl5Vx754o3/bVnQbQMweGF2G3Fg3AccEINoBnR1QYACGHCCaAUoZpqAVY8eGQGYY0a66Ksr jrrisCPZVoADVp3aZ6DlFYOAUAnguABYb2Yk6aWbftqUth94W4m45xU6bL35dsHvuYnWGt5dxX74 5weCttlQdgdgdXExYBXgAcRdWJVjRjB/YOkmAgi181APAH3uJi7PXPGKAd+aEqELYD1bmydvteLP v3VBY8id4BwW3dHo3f8RdoUXg3gXBFZgAEgAZ/f11G+vvGfIofddjMkXcGGBB5pPHY3TF/5475Ud B1977r1fG1S8YWc/dt95FZp+m09vwHns32/l/vyLt39c/hvAqnbXOtfpb3/XUxT9cLc/NBDNYafz mgtgFTo0zIxgtApgzBIGPgi6QILwE0D3LBi96P2vdQyEnwsw6L9GVBAWLawZCpsgQxQabII0POAM QdXA2i3QZrPbHs54proH+AtziNObAywIvoelanRog9zlmEY7IorqWya8WOKccLohskuIKwRezU62 xCaWYow6NODmjpi/hOFPEtq63sl+2IQwXtFj1WuCAVZVwi1Ozn0G+57/ElKmLupti1cMgJnkaFay 9eExVBPUIh1Z1oQB6G1p2+Ij6naYPzoWklymOKETUzfKjjksjnLcWR7rqLw+rtKUeUJWFhHogg8q IYROCEACYBUq950QkfGaHcHYdUsQGq1iBoAVKlu5wlQKq1mzXGMsTbnLXjYSY6x0ZiW56MBdwapf qZxmLaVJvUAJa5CkNGLnktiIprnLm85q4LZw1UwqKqGd4BvdL/UXS4uNKgHpRCc342lOJ7zzfNkE Zi0LqsD8CYBocHRhJxX6SIP+iVdvXGP25JjOaVGOhQ/IoBgEJtFtJexzluyoE4PZzUmMMqMbXKEN XRqJ0fkwFDQl6Bp1/9q6ZY5NfjaDabw0uk1CbQuHRlUC0bSVQ/a1bXyELB/sMKe3JjAVWV573t/6 ydCNwi+pK2ybRGsK1FKMdaJrRCsPl9e5sjq0m2FVpx6VMECRUg9WHp0czKI6Oph9romja+P7GiAu I+rVirLDphY1MVRLrmqk7zsewubaVyuKYrIfm6vxQrW75KmPrDt9n2PrCtmL+gmMrCqd/vbKiLxm SwEH4Jgyp2pLtyGxashM3ex41Vo0vLaVZSOgOv1pztSG04O37ZvcGhrb2cJqaqRg6uAK11DITRdu zG2madU4WnIGUbVzPSfkEsZPfRHNqbY9mrhQFdpCimp8QjOseummW8VtPQ5gquyuM8vbMXa9d1SQ 5BV7TxXaUQA4sfr65MtStzweHjBn5F0sycZbsISqElaR3SPtClBYXxawVqHClYab6QKrUvCuGlwk qhagYZLpt6xiUxslayUuWcFyWx0WF7FcUeNQ3VjAtTtXwNIF5P3NbIiibSaMAac2IVPyU1GW8pSp XGUrXxnLWdbylrncZS9/GcxhFvOYyVxmM58ZzWlW85rZ3GY3vxnOcZbznOlcZzvfGc951vOe+dxn P/8Z0IEWtKSCAAA7 ------586849920138538984-- From hurley@acis.com Sun Apr 3 23:00:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19492 for ; Sun, 3 Apr 2005 23:00:59 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHxb-00021A-Mj for aaa-archive@ietf.org; Sun, 03 Apr 2005 23:09:09 -0400 Received: from 201009025175.user.veloxzone.com.br ([201.9.25.175]) by mx2.foretec.com with smtp (Exim 4.24) id 1DIHpi-0000DI-1X for aaa-archive@ietf.org; Sun, 03 Apr 2005 23:00:59 -0400 Message-ID: <485c01c538c0$ba2475e5$a0071a93@acis.com> From: "Vanessa J. Smith" To: aaa-archive@ietf.org Subject: =?iso-8859-1?B?QWxsIHNvZnR3YXJlIC0gYm90dG9tIHByaWNlcw==?= Date: Mon, 04 Apr 2005 02:43:49 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_97E039D7.62A4646A" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.0 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_97E039D7.62A4646A Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_325CD11E.C0577198" ------=_NextPart_001_0001_325CD11E.C0577198 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get access to all the software imaginable for unbelievably low prices! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Go visit us at: http://www.oemunlimited.biz Sincerely, Vanessa J. Smith _____________________________________________________ To stop further mailings, go here: http://www.oemunlimited.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_325CD11E.C0577198 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Get access to all the software you ever imagined for prices substantially lower than in stores!
Our software is 2-10 times cheaper than sold by our competitors.

Just a few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... Visit us at:

http://www.oemunlimited.biz

Sincerely,
Vanessa Smith


_____________________________________________________
To be taken off future campaigns, go here: http://www.oemunlimited.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_325CD11E.C0577198-- ------=_NextPart_000_0000_97E039D7.62A4646A-- From owner-aaa-wg@merit.edu Mon Apr 4 03:34:07 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01546 for ; Mon, 4 Apr 2005 03:34:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D16291262; Mon, 4 Apr 2005 03:32:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 404049126C; Mon, 4 Apr 2005 03:32: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 A297F91262 for ; Mon, 4 Apr 2005 03:32:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 87EC35828D; Mon, 4 Apr 2005 03:32:24 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 64FDE58285 for ; Mon, 4 Apr 2005 03:32:24 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 69893186E; Mon, 4 Apr 2005 03:32:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by testbed9.merit.edu (Postfix) with ESMTP id EF5F0181D for ; Mon, 4 Apr 2005 03:32:23 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j347WBG20043; Mon, 4 Apr 2005 10:32:11 +0300 (EET DST) X-Scanned: Mon, 4 Apr 2005 10:29:04 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j347T4Tc009250; Mon, 4 Apr 2005 10:29:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 0098WJ6w; Mon, 04 Apr 2005 10:28:10 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j347S9U29238; Mon, 4 Apr 2005 10:28:09 +0300 (EET DST) Received: from [127.0.0.1] ([172.21.39.90]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Apr 2005 10:25:33 +0300 Message-ID: <4250EBED.8090705@nokia.com> Date: Mon, 04 Apr 2005 10:25:33 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu, Jari Arkko Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2005 07:25:33.0240 (UTC) FILETIME=[7CCDF380:01C538E7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have filed his issue: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue47 Now, I asked sometime ago what would be the problem in having grouped AVPs that, in turn, contain Digest-* attributes imported from RADIUS. The answer I got (Jari), at that time, was, there shouldn't be a problem. I still belive that grouped AVPs constitute a powerful mechanism to avoid problems (such as sequencing, repetition, etc.). I think that Jari's argument is weak ("this will create some overload to the gateway"). The gateway will need to do a bunch of other functions to translate RADIUS to Diameter, so I am not for the idea of constraining the protocol (Diameter) just because the gateway (to RADIUS) will have some extra load. I believe this extra load is negligible compared to the rest of AVPs the gateway will need to rebuild. My opinion: I am in favor of leaving the grouped AVPs as they are. /Miguel Bernard Aboba wrote: > Note: Jari is opening a new issue within the Diameter SIP document. > > ---------- Forwarded message ---------- > Date: Thu, 24 Mar 2005 16:49:18 +0200 > From: Jari Arkko > To: radiusext@ops.ietf.org > Subject: digest issue 11 closure > > Checking from the issue tracker this issue and comparing > it against -01. Here's what I found: > > >> Due to the weaknesses of Digest authentication (see Section 6), >> >>Section 6 does not talk about the weaknesses of Digest authentication >>(original RFC reference might give you some security considerations; >>I'm not sure if there's any other document that would talk the >>issue). >> >> > > > Ok. > > >> Due to the weaknesses of Digest authentication (see Section 6), >> PKI-based authentication and encryption mechanisms have been >> introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However, >> >> >>Digest, TLS, and S/MIME are not necessarily in direct >>competition with each other, as they provide slightly different >>services. For instance, TLS is hbh, and Digest gives you >>freshness which S/MIME does not. Plus all three protect >>different parts of the SIP message. >> >> >>Suggestion: soften the above statement a bit. >> >> > > Ok (but a nit: s/The majority of today's SIP clients only supports HTTP > digest./ > The majority of today's SIP clients only support HTTP digest, however./ > (I think Bernard caught this already so this is not a reason to keep my > issue alive.) > > >> SIP service providers whishing to authenticate their clients have the >> following options: they can >> o build a PKI and wait for interopable S/MIME capable SIP >> implementations, >> o build a PKI and wait for SIP implementations supporting TLS with >> client-side certificates, >> o replace their existing RADIUS infrastructure with DIAMETER >> [RFC3588], when DIAMETER supports HTTP Digest authentication, >> o use TLS for server authentication and plaintext passwords (Basic) >> for client authentication, which can be done with standard RADIUS, >> o upgrade their existing RADIUS servers with the functionality >> described in this document >> >> >> >> >> PKI solutions only cover authentication, not authorization (EAP could >> change this, but its use with SIP is not standardized). TLS / Basic >> authentication works only with the limited number of SIP devices that >> implement TLS. Basic authentication has been deprecated for SIP in >> [RFC3261]. >> >> >>Somehow the above arguments feel a bit out of place here. Just >>state that Digest is widely used in SIP, and leave it at that :-) >> >> > > Ok. > > >> PKI solutions only cover authentication, not authorization (EAP could >> change this, but its use with SIP is not standardized). TLS / Basic >> authentication works only with the limited number of SIP devices that >> implement TLS. Basic authentication has been deprecated for SIP in >> [RFC3261]. >> >> >> >> >> Current RADIUS-based AAA infrastructures have been built and debugged >> over years. Deficiencies of RADIUS have been mitigated with >> proprietary (ie costly) extensions. Operators are therefore >> reluctant to replace their RADIUS infrastructure in order to enable a >> single new authentication mechanism. >> >> >>Same as above. And I'm not sure all deficiences have been >>mitigated. >> >> > > Ok. > > >> DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG, >> DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP, >> DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that >> will be assigned by IANA, if this specification becomes a working >> group or IESG document. >> >> >>Here's an idea: I'd prefer the attributes in this and the Diameter >>draft to be constructed with the following rules: >> >> >>(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP, >> and Dig-Authp could all use the same attribute? They all have >> the same syntax in HTTP (param=value). >> >> >>(2) If both RADIUS and Diameter are going to define the attributes, >> IMHO it would make sense to allocate them from the RADIUS space >> so a conversion box would not have to map attributes. >> >> >> Alternative idea: use some of the extended RADIUS attribute >> format ideas and allocate the numbers from the Diameter space. >> >> >>(3) Use exactly the set of attributes for the pure digest function >> (I did not check if this is already the case). >> >> > > Ok, this is mostly as I wanted it to be in the Radius document. > However, I wonder if the current Diameter document should > use individual AVPs instead of Grouped AVP: > > SIP-Authenticate ::= < AVP Header: xx12 > > { Digest-Realm } > { Digest-Nonce } > [ Digest-Domain ] > [ Digest-Opaque ] > [ Digest-Stale ] > [ Digest-Algorithm ] > [ Digest-QoP ] > [ Digest-HA1] > * [ Digest-Auth-Param ] > * [ AVP ] > > > Because translating this grouped AVP appears to require > additional work from a gateway, no? Bernard/Miguel, can > you file on issue to the Diameter document on this. > > >> +-----+ (1) +-----+ +-----+ >> | |==========>| | (2) | | >> | | | |---------->| | >> | | | | (3) | | >> | | (4) | |<----------| | >> | |<==========| | | | >> | | (5) | | | | >> | |==========>| | | | >> | A | | B | (6) | C | >> | | | |---------->| | >> | | | | (7) | | >> | | | |<----------| | >> | | (8) | | | | >> | |<==========| | | | >> +-----+ +-----+ +-----+ >> >> >>The choice between the server and client generated >>nonces: is there some guidance on how the client knows >>which one to do? if it believes it may have a user that >>does Digest AKA then it should do use the server generated >>scheme? But how would it know this in a roaming case? >> >> >>Other ideas? >> > > > This has been raised by Bernard too, apparently we > didn't do good enough job to fix it. > > Conclusion: close issue 11. Bernard's roaming issue > still needs to be kept alive, and I'm suggesting one > new issue on the Diameter SIP document. > > --Jari > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Apr 4 04:14:53 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04264 for ; Mon, 4 Apr 2005 04:14:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B799A9126A; Mon, 4 Apr 2005 04:14:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 810629126B; Mon, 4 Apr 2005 04:14:46 -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 5EE5B9126A for ; Mon, 4 Apr 2005 04:14:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 09B2058288; Mon, 4 Apr 2005 04:14:45 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id E5FB058282 for ; Mon, 4 Apr 2005 04:14:44 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id EB628186E; Mon, 4 Apr 2005 04:14:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by testbed9.merit.edu (Postfix) with ESMTP id 83E49181D for ; Mon, 4 Apr 2005 04:14:44 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B736189862; Mon, 4 Apr 2005 11:14:43 +0300 (EEST) Message-ID: <4250F770.3090908@kolumbus.fi> Date: Mon, 04 Apr 2005 11:14:40 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Cc: Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) References: <4250EBED.8090705@nokia.com> In-Reply-To: <4250EBED.8090705@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Let me expand on what I meant with "additional work" that a R/D gateway needs to do. As originally envisioned, the Diameter translation gateway was expected to be a mindless automaton, blindly copying attributes to slightly different format. This would be great, as the introduction of a new application or AVP would not impact a gateway, or would only have a small impact. But we have actually come quite far from this ideal, the current translation rules for applications contain a number of attribute specific processing rules. I realize we have already started on this path, and there's no turning back. Nevertheless, minimizing the necessary "coding" or "mapping table construction" for translation gateways is still valuable, as the simpler they are the easier they are to implement. I also realize that there are conflicting requirements. Ability to clearly associate a particular set of attributes to a group can be problematic (but doesn't that have to be solved for RADIUS SIP anyway?). And grouping things inside on Grouped AVP looks much nicer. --Jari Miguel Garcia wrote: > I have filed his issue: > > http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue47 > > Now, I asked sometime ago what would be the problem in having grouped > AVPs that, in turn, contain Digest-* attributes imported from RADIUS. > The answer I got (Jari), at that time, was, there shouldn't be a problem. > > I still belive that grouped AVPs constitute a powerful mechanism to > avoid problems (such as sequencing, repetition, etc.). I think that > Jari's argument is weak ("this will create some overload to the > gateway"). The gateway will need to do a bunch of other functions to > translate RADIUS to Diameter, so I am not for the idea of constraining > the protocol (Diameter) just because the gateway (to RADIUS) will have > some extra load. I believe this extra load is negligible compared to > the rest of AVPs the gateway will need to rebuild. > > My opinion: I am in favor of leaving the grouped AVPs as they are. > From owner-aaa-wg@merit.edu Mon Apr 4 04:49:39 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07036 for ; Mon, 4 Apr 2005 04:49:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 710AF9126D; Mon, 4 Apr 2005 04:49:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DEA991270; Mon, 4 Apr 2005 04:49: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 73F569126D for ; Mon, 4 Apr 2005 04:49:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48A1758288; Mon, 4 Apr 2005 04:49:16 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 005BF58285 for ; Mon, 4 Apr 2005 04:49:15 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 0665D187A; Mon, 4 Apr 2005 04:49:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by testbed9.merit.edu (Postfix) with ESMTP id 7848A1874 for ; Mon, 4 Apr 2005 04:49:15 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j348n6G09806; Mon, 4 Apr 2005 11:49:06 +0300 (EET DST) X-Scanned: Mon, 4 Apr 2005 11:45:46 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j348jk85016843; Mon, 4 Apr 2005 11:45:46 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00hMQZ7M; Mon, 04 Apr 2005 11:45:43 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j348jfU04285; Mon, 4 Apr 2005 11:45:41 +0300 (EET DST) Received: from [127.0.0.1] ([172.21.39.90]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Apr 2005 11:45:35 +0300 Message-ID: <4250FEAF.2040004@nokia.com> Date: Mon, 04 Apr 2005 11:45:35 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jari Arkko Cc: Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) References: <4250EBED.8090705@nokia.com> <4250F770.3090908@kolumbus.fi> In-Reply-To: <4250F770.3090908@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2005 08:45:35.0455 (UTC) FILETIME=[AB25CEF0:01C538F2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Minimizing the "coding" or "mapping table construnction" is a valuable argument when it has an impact on the processing time. But as I said before, this time is negligible compared to the time the gateway will use to process a request, so I don't see the point in destroying the clear structure we have in the Diameter SIP app for no visible gain. /Miguel Jari Arkko wrote: > > Let me expand on what I meant with "additional work" that > a R/D gateway needs to do. As originally envisioned, the Diameter > translation gateway was expected to be a mindless automaton, > blindly copying attributes to slightly different format. This would > be great, as the introduction of a new application or AVP would > not impact a gateway, or would only have a small impact. But we have > actually come quite far from this ideal, the current translation > rules for applications contain a number of attribute specific > processing rules. > > I realize we have already started on this path, and there's no > turning back. Nevertheless, minimizing the necessary "coding" > or "mapping table construction" for translation gateways is > still valuable, as the simpler they are the easier they are to > implement. > > I also realize that there are conflicting requirements. Ability > to clearly associate a particular set of attributes to a group > can be problematic (but doesn't that have to be solved for > RADIUS SIP anyway?). And grouping things inside on Grouped > AVP looks much nicer. > > --Jari > > Miguel Garcia wrote: > >> I have filed his issue: >> >> http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue47 >> >> Now, I asked sometime ago what would be the problem in having grouped >> AVPs that, in turn, contain Digest-* attributes imported from RADIUS. >> The answer I got (Jari), at that time, was, there shouldn't be a problem. >> >> I still belive that grouped AVPs constitute a powerful mechanism to >> avoid problems (such as sequencing, repetition, etc.). I think that >> Jari's argument is weak ("this will create some overload to the >> gateway"). The gateway will need to do a bunch of other functions to >> translate RADIUS to Diameter, so I am not for the idea of constraining >> the protocol (Diameter) just because the gateway (to RADIUS) will have >> some extra load. I believe this extra load is negligible compared to >> the rest of AVPs the gateway will need to rebuild. >> >> My opinion: I am in favor of leaving the grouped AVPs as they are. >> > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Apr 4 05:02:23 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08358 for ; Mon, 4 Apr 2005 05:02:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B855991270; Mon, 4 Apr 2005 05:00:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BBBC9127D; Mon, 4 Apr 2005 05:00:46 -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 D26BC91270 for ; Mon, 4 Apr 2005 05:00:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B5DC358288; Mon, 4 Apr 2005 05:00:41 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 9CC8C58285 for ; Mon, 4 Apr 2005 05:00:41 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id A24B3187A; Mon, 4 Apr 2005 05:00:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis837.omnitel.it (mailout-2.omnitel.it [194.20.71.226]) by testbed9.merit.edu (Postfix) with ESMTP id 41BBA186E for ; Mon, 4 Apr 2005 05:00:40 -0400 (EDT) Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id j3490cJM020290 for ; Mon, 4 Apr 2005 11:00:38 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Apr 2005 11:00:35 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C538F4.C3005D26" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [AAA-WG]: RE: AAA Transport Profile and Application Failure Date: Mon, 4 Apr 2005 11:00:34 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB90823D77C@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: RE: AAA Transport Profile and Application Failure Thread-Index: AcU22bdDhjBe57SIS1uCOY0QltBMJwCGagLQ From: "STURA Marco Consultant" To: "Rakesh Mehta" , Cc: X-OriginalArrivalTime: 04 Apr 2005 09:00:35.0141 (UTC) FILETIME=[C366FF50:01C538F4] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C538F4.C3005D26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rakesh Mehta wrote =20 >As per section 6.1 of RFC 3588(as mentioned in this mail), even diameter stack is working in server mode; it can create DIAMETER_UNABLE_TO_DELIVER >message with E bit set and send to proxy if local application is not available to process the message. =20 >I believe this should be true for client side also, because the same scenario can occur for client side. can any person verify for me please??? =20 I don't think this is the case. A Diameter client is not generating responses for requests it generated, clients just wait for answers. However, your case should be true for server initiated requests (e.g. RAR). =20 Regards Marco=20 =20 ------_=_NextPart_001_01C538F4.C3005D26 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rakesh Mehta wrote

 

>As per section= 6.1 of RFC 3588(as mentioned in this mail), even diameter stack is working in = server mode; it can create DIAMETER_UNABLE_TO_DELIVER >message with E = bit set and send to proxy if local application is not available to process the = message.

 

>I believe this should = be true for client side also, because the same scenario can occur for client side. can any person verify for me please???

 

I don’t think this is the = case. A Diameter client is not generating responses for requests it generated, clients = just wait for answers. However, your case should be true for server initiated = requests (e.g. RAR).

 

Regards

Marco

 

------_=_NextPart_001_01C538F4.C3005D26-- From owner-aaa-wg@merit.edu Mon Apr 4 05:18:31 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09514 for ; Mon, 4 Apr 2005 05:18:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE6E391247; Mon, 4 Apr 2005 05:18:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47AC191272; Mon, 4 Apr 2005 05:18: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 092C291247 for ; Mon, 4 Apr 2005 05:18:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE14858288; Mon, 4 Apr 2005 05:18:17 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id D6FBD58285 for ; Mon, 4 Apr 2005 05:18:17 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id DC2C3186E; Mon, 4 Apr 2005 05:18:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by testbed9.merit.edu (Postfix) with ESMTP id B316F181D for ; Mon, 4 Apr 2005 05:18:17 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0EBB389862; Mon, 4 Apr 2005 12:18:16 +0300 (EEST) Message-ID: <42510654.4000602@kolumbus.fi> Date: Mon, 04 Apr 2005 12:18:12 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Cc: Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) References: <4250EBED.8090705@nokia.com> <4250F770.3090908@kolumbus.fi> <4250FEAF.2040004@nokia.com> In-Reply-To: <4250FEAF.2040004@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > Minimizing the "coding" or "mapping table construnction" is a valuable > argument when it has an impact on the processing time. But as I said > before, this time is negligible compared to the time the gateway will > use to process a request, so I don't see the point in destroying the > clear structure we have in the Diameter SIP app for no visible gain. > Perhaps I didn't make my argument clear, because you seem to be talking about a different tradeoff than I am. My worry was not anything that happens at run-time, I'm sure a translation gateway spends less CPU time re-organizing AVPs than something else, say TLS. My worry was, however, about the need to have a specific translation rule, which increases *implementation* time and effort. --Jari From owner-aaa-wg@merit.edu Mon Apr 4 05:56:52 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12402 for ; Mon, 4 Apr 2005 05:56:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6077091274; Mon, 4 Apr 2005 05:56:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29D1991275; Mon, 4 Apr 2005 05:56:45 -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 E583191274 for ; Mon, 4 Apr 2005 05:56:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCAB258285; Mon, 4 Apr 2005 05:56:43 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 890DC58282 for ; Mon, 4 Apr 2005 05:56:43 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 8E8C11874; Mon, 4 Apr 2005 05:56:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by testbed9.merit.edu (Postfix) with ESMTP id 0337B186E for ; Mon, 4 Apr 2005 05:56:42 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j349uYF20396; Mon, 4 Apr 2005 12:56:34 +0300 (EET DST) X-Scanned: Mon, 4 Apr 2005 12:53:43 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j349rhfQ025727; Mon, 4 Apr 2005 12:53:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00saw2rQ; Mon, 04 Apr 2005 12:53:40 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j349axU10137; Mon, 4 Apr 2005 12:36:59 +0300 (EET DST) Received: from [127.0.0.1] ([172.21.39.90]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Apr 2005 12:36:57 +0300 Message-ID: <42510AB8.9090205@nokia.com> Date: Mon, 04 Apr 2005 12:36:56 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jari Arkko Cc: Bernard Aboba , aaa-wg@merit.edu, "Beck01, Wolfgang" Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) References: <4250EBED.8090705@nokia.com> <4250F770.3090908@kolumbus.fi> <4250FEAF.2040004@nokia.com> <42510654.4000602@kolumbus.fi> In-Reply-To: <42510654.4000602@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2005 09:36:57.0065 (UTC) FILETIME=[D7EE2D90:01C538F9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hmmmm... I see the point. But I still believe a translation rule is needed, but not in the gateway, but in the RADIUS client (so this makes also the rule needed in the gateway). Imagine: how is the SIP-server/RADIUS-client going to determine that it has to generate an Authentication-Info header when the RADIUS server returns a next nonce? I guess there is a rule that says "if Digest-Nextnonce attribute present, then generate Authentication-Info header in SIP". So this is the rule between RADIUS and SIP. In Diameter SIP app, we don't have this problem, because the Digest-Nextnonce would be part of the SIP-Authentication-Info AVP. So the point I want to make is that, due to the lack of grouped attributes in RADIUS, you do need translation rules in RADIUS in order to generate the appropriate HTTP/SIP digest header. And we don't have this problem in Diameter due to the usage of grouped AVPs. So the translation rules are in the RADIUS part of the gateway, not in the Diameter. You should fix the RADIUS draft if possible, rather than extend translation rules to native Diameter applications. /Miguel Jari Arkko wrote: > Miguel Garcia wrote: > >> Minimizing the "coding" or "mapping table construnction" is a valuable >> argument when it has an impact on the processing time. But as I said >> before, this time is negligible compared to the time the gateway will >> use to process a request, so I don't see the point in destroying the >> clear structure we have in the Diameter SIP app for no visible gain. >> > Perhaps I didn't make my argument clear, because you seem > to be talking about a different tradeoff than I am. My worry was > not anything that happens at run-time, I'm sure a translation > gateway spends less CPU time re-organizing AVPs than something > else, say TLS. > > My worry was, however, about the need to have a specific > translation rule, which increases *implementation* time > and effort. > > --Jari > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Apr 4 07:58:03 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22583 for ; Mon, 4 Apr 2005 07:58:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 800A791264; Mon, 4 Apr 2005 07:57:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B8E491277; Mon, 4 Apr 2005 07:57:55 -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 E09E691264 for ; Mon, 4 Apr 2005 07:57:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C816B5828D; Mon, 4 Apr 2005 07:57:53 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 83A9358288 for ; Mon, 4 Apr 2005 07:57:53 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 893621853; Mon, 4 Apr 2005 07:57:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tcmail21.telekom.de (tcmail21.telekom.de [217.6.95.235]) by testbed9.merit.edu (Postfix) with ESMTP id 13EBB181D for ; Mon, 4 Apr 2005 07:57:52 -0400 (EDT) Received: from g9jbq.mgb01.telekom.de (g9jbq.mgb01.telekom.de [164.20.31.5]) by tcmail21.dmz.telekom.de with ESMTP; Mon, 4 Apr 2005 13:57:51 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <2H6J7QLB>; Mon, 4 Apr 2005 13:57:51 +0200 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FEA0@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com, jari.arkko@kolumbus.fi Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: AW: [AAA-WG]: digest issue 11 closure (fwd) Date: Mon, 4 Apr 2005 13:57:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel wrote: > Hmmmm... I see the point. But I still believe a translation rule is > needed, but not in the gateway, but in the RADIUS client (so > this makes > also the rule needed in the gateway). > > Imagine: how is the SIP-server/RADIUS-client going to > determine that it > has to generate an Authentication-Info header when the RADIUS server > returns a next nonce? I guess there is a rule that says "if > Digest-Nextnonce attribute present, then generate Authentication-Info > header in SIP". So this is the rule between RADIUS and SIP. > The draft is quite explicit when to generate Authentication-Info: The RADIUS client constructs an Authentication-Info header: o If the Access-Accept message contains a Digest-Response-Auth attribute, the RADIUS client checks the Digest-Qop attribute: * If the Digest-Qop attribute's value is 'auth' or not specified, the RADIUS client puts the Digest-Response-Auth attribute's content into the Authentication-Info header's 'rspauth' directive of the HTTP-style response. * If the Digest-Qop attribute's value is 'auth-int', the RADIUS client ignores the Access-Accept message and behaves like it had received an Access-Reject message (Digest-Response-Auth can't be correct as the RADIUS server does not know the contents of the HTTP-style response's body). o If the Access-Accept message contains a Digest-HA1 attribute, the RADIUS client checks the 'qop' and 'algorithm' directives in the Authorization header of the HTTP-style request it wants to authorize: * If the 'qop' directive is missing or its value is 'auth', the RADIUS client ignores the Digest-HA1 attribute. It does not include an Authentication-Info header into its HTTP-style response. * If the 'qop' directive's value is 'auth-int' and at least one of the following conditions is true, the RADIUS client calculates the contents of the HTTP-style response's 'rspauth' directive: + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5-sess'. + The messages between RADIUS client and RADIUS server are protected with IPsec (see Section 8). It creates the HTTP-style response message and calculates the hash of this message's body. It uses the result and the Digest-URI attribute's value of the corresponding Access-Request message to perform the H(A2) calculation. It takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop values of the corresponding Access-Request and the Digest-HA1 attribute's value to finish the computation of the 'rspauth' value. o If the Access-Accept message contains neither a Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client will not create an Authentication-Info header for its HTTP-style response. Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany From lacos2005@yahoo.fr Mon Apr 4 09:08:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03154 for ; Mon, 4 Apr 2005 09:08:04 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIREQ-0002eM-5C for aaa-archive@ietf.org; Mon, 04 Apr 2005 09:03:06 -0400 Received: from [213.154.94.65] (helo=2mails686.com) by mx2.foretec.com with smtp (Exim 4.24) id 1DIR6N-0007DP-Q0 for aaa-archive@ietf.org; Mon, 04 Apr 2005 08:54:50 -0400 From: "Lansana Fofana" Reply-To: lacos2005@yahoo.fr To: aaa-archive@ietf.org Date: Mon, 4 Apr 2005 14:54:36 +0200 Subject: This letter is strictly personal from Dakar -SENEGAL X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 15.0 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Att=3ASir Good day=2CI know you'll receive this proposal beyond your imagination=2C surprise and some skeptism=2C based on the fact that we never had any prior discussion to this matter nor do we by any means seen or known each other before=2Cnevertheless I would like you to treat the letter as a matter of urgency and accord it every necessary attention required on transaction of its magnitude=2E I got your contact in cause of a serious search the for a reliable foreign partner=2E I'm Lansana Cosmos the son of a late sierra leonian businessman=2C late Dr=2E Cosmos FOFANA the owner of RMS=29mining company in Sierra leone =2EWho died some years ago when the revolutionary united front rebels attacked Makeni town=2C Sierra leone=2E Following the cease fire agreement which was brokerred last year with the help of United Nation peace keeping troops=28UNASIL=29=2CI used the oppoturnity to leave the country with a very important document of=28US$9=2E400=2E000=29 Nine million four hundred thousand U=2ES Dollars deposited by my late father in security company in Dakar Senegal on my name as the next of kin=2E This money was realised from diamond export=2C now i and my mother are seeking asylum in Dakar Senegal under=28UNHCR=29=2E My main reason of contacting you is that I received an information from the Security Company warning that I should make haste to dislodge the money or I loose it to high interest rate which has been pilling up since 1997 up till date=2E They advised I should present an individual=2Corganisation =2F company as the beneficiary of the amount since the money cannot be released to me as a client considering my status here as a refugee=2E I only want this done this way because your country is politically stable for any profitable for investment=2C The document are with me right now in Senegal=2C it will be faxed to you upon request=2Ewhich will emphasis the authenticity of the transfer=2E However I contacted with the notion that you'll have good knowledge on international commercial investment=2E For your assistance and co-operation we will give you 10%of the total sum realised after the sucessfull transfer of this money=2E Please kindly communicate your acceptance of this proposal so that we can discuss the modalities of seeing this transaction through=2E We count on you greatly for your assistance=2E Awaiting to to hear from you soon=2E Your Sincerely Lansana COSMOS=2E From owner-aaa-wg@merit.edu Mon Apr 4 10:19:28 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11807 for ; Mon, 4 Apr 2005 10:19:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 039E991280; Mon, 4 Apr 2005 10:19:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26DAA91281; Mon, 4 Apr 2005 10:19:16 -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 0F7ED91280 for ; Mon, 4 Apr 2005 10:19:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF9CC58288; Mon, 4 Apr 2005 10:19:13 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id D6A5B58283 for ; Mon, 4 Apr 2005 10:19:13 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id DBC2D1853; Mon, 4 Apr 2005 10:19:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by testbed9.merit.edu (Postfix) with ESMTP id 64BA3181D for ; Mon, 4 Apr 2005 10:19:12 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j34EJ2g25160; Mon, 4 Apr 2005 17:19:02 +0300 (EET DST) X-Scanned: Mon, 4 Apr 2005 17:16:10 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j34EGAW5016681; Mon, 4 Apr 2005 17:16:10 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00NFjQHr; Mon, 04 Apr 2005 17:16:08 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j34EG8U06974; Mon, 4 Apr 2005 17:16:08 +0300 (EET DST) Received: from [127.0.0.1] ([172.21.39.90]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Apr 2005 17:15:53 +0300 Message-ID: <42514C17.3040105@nokia.com> Date: Mon, 04 Apr 2005 17:15:51 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: jari.arkko@kolumbus.fi, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: AW: [AAA-WG]: digest issue 11 closure (fwd) References: <76C27E1CE3FFC847B4D51C645D6F42AA15FEA0@E9JDF.mgb01.telekom.de> In-Reply-To: <76C27E1CE3FFC847B4D51C645D6F42AA15FEA0@E9JDF.mgb01.telekom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2005 14:15:53.0045 (UTC) FILETIME=[CF5A1050:01C53920] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Right, this is the "rule" that allows the SIP server to do a translation and determine when to create an Authentication-Info header. This is the type of rules that Jari was trying to avoid, and I have been saying that is not possible in RADIUS. And this is the type of rule I am trying to avoid in Diameter. /Miguel Beck01, Wolfgang wrote: > Miguel wrote: > >>Hmmmm... I see the point. But I still believe a translation rule is >>needed, but not in the gateway, but in the RADIUS client (so >>this makes >>also the rule needed in the gateway). >> >>Imagine: how is the SIP-server/RADIUS-client going to >>determine that it >>has to generate an Authentication-Info header when the RADIUS server >>returns a next nonce? I guess there is a rule that says "if >>Digest-Nextnonce attribute present, then generate Authentication-Info >>header in SIP". So this is the rule between RADIUS and SIP. >> > > The draft is quite explicit when to generate Authentication-Info: > > The RADIUS client constructs an Authentication-Info header: > o If the Access-Accept message contains a Digest-Response-Auth > attribute, the RADIUS client checks the Digest-Qop attribute: > * If the Digest-Qop attribute's value is 'auth' or not specified, > the RADIUS client puts the Digest-Response-Auth attribute's > content into the Authentication-Info header's 'rspauth' > directive of the HTTP-style response. > * If the Digest-Qop attribute's value is 'auth-int', the RADIUS > client ignores the Access-Accept message and behaves like it > had received an Access-Reject message (Digest-Response-Auth > can't be correct as the RADIUS server does not know the > contents of the HTTP-style response's body). > o If the Access-Accept message contains a Digest-HA1 attribute, the > RADIUS client checks the 'qop' and 'algorithm' directives in the > Authorization header of the HTTP-style request it wants to > authorize: > * If the 'qop' directive is missing or its value is 'auth', the > RADIUS client ignores the Digest-HA1 attribute. It does not > include an Authentication-Info header into its HTTP-style > response. > * If the 'qop' directive's value is 'auth-int' and at least one > of the following conditions is true, the RADIUS client > calculates the contents of the HTTP-style response's 'rspauth' > directive: > + The algorithm directive's value is 'MD5-sess' or > 'AKAv1-MD5-sess'. > + The messages between RADIUS client and RADIUS server are > protected with IPsec (see Section 8). > It creates the HTTP-style response message and calculates the > hash of this message's body. It uses the result and the > Digest-URI attribute's value of the corresponding > Access-Request message to perform the H(A2) calculation. It > takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and > Digest-Qop values of the corresponding Access-Request and the > Digest-HA1 attribute's value to finish the computation of the > 'rspauth' value. > o If the Access-Accept message contains neither a > Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client > will not create an Authentication-Info header for its HTTP-style > response. > > > > Wolfgang > > -- > T-Systems > Next Generation IP Services and Systems > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Apr 4 10:33:56 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13256 for ; Mon, 4 Apr 2005 10:33:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 085CA91281; Mon, 4 Apr 2005 10:30:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1635F91285; Mon, 4 Apr 2005 10:30: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 3124491281 for ; Mon, 4 Apr 2005 10:30:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17E0058288; Mon, 4 Apr 2005 10:30:29 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 0059058283 for ; Mon, 4 Apr 2005 10:30:28 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 01E5B185E; Mon, 4 Apr 2005 10:30:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tcmail21.telekom.de (tcmail21.telekom.de [217.6.95.235]) by testbed9.merit.edu (Postfix) with ESMTP id 890B11853 for ; Mon, 4 Apr 2005 10:30:28 -0400 (EDT) Received: from g9jbq.mgb01.telekom.de (g9jbq.mgb01.telekom.de [164.20.31.5]) by tcmail21.dmz.telekom.de with ESMTP; Mon, 4 Apr 2005 16:30:26 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <2H6J76SJ>; Mon, 4 Apr 2005 16:30:25 +0200 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FEA2@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: jari.arkko@kolumbus.fi, aboba@internaut.com, aaa-wg@merit.edu Subject: AW: AW: [AAA-WG]: digest issue 11 closure (fwd) Date: Mon, 4 Apr 2005 16:30:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel wrote: > Right, this is the "rule" that allows the SIP server to do a translation > and determine when to create an Authentication-Info header. > This is the type of rules that Jari was trying to avoid, and I have been > saying that is not possible in RADIUS. And this is the type of rule I am > trying to avoid in Diameter. But you have Digest-HA1, Digest-Entity-Body-Hash, etc in Diameter as well. Or has this changed? I was under the impression that a RADIUS/Diameter GW can just map RADIUS attributes to Diameter AVPs and vice versa. The only thing the GW has to know is, what RADIUS attributes must be placed into grouped AVPs. It doesn't have to decide whether to send an Authentication-Info header. What am I missing? Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany From owner-aaa-wg@merit.edu Mon Apr 4 10:34:51 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13355 for ; Mon, 4 Apr 2005 10:34:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3E8291285; Mon, 4 Apr 2005 10:34:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A18B91282; Mon, 4 Apr 2005 10:34:44 -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 1F40D91285 for ; Mon, 4 Apr 2005 10:34:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6990458288; Mon, 4 Apr 2005 10:34:40 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id BF88F582C2 for ; Mon, 4 Apr 2005 10:34:39 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 7C57D1853; Mon, 4 Apr 2005 10:34:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by testbed9.merit.edu (Postfix) with ESMTP id 462B2185E for ; Mon, 4 Apr 2005 10:34:38 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA04314 for ; Mon, 4 Apr 2005 10:35:27 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma004295; Mon, 4 Apr 05 10:34:40 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 04 Apr 2005 10:33:50 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 04 Apr 2005 10:33:50 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 10:33:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: digest issue 11 closure (fwd) Date: Mon, 4 Apr 2005 10:33:49 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103229D@MAANDMBX2.ets.enterasys.com> Thread-Topic: [AAA-WG]: digest issue 11 closure (fwd) Thread-Index: AcU4/KB4EXyB6+H5SN2ioj/fmsyKdgAJRwxA From: "Nelson, David" To: X-OriginalArrivalTime: 04 Apr 2005 14:33:50.0139 (UTC) FILETIME=[515990B0:01C53923] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:98.9754 M:94.6171 P:95.9108 R:95.9108 S:67.6478 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Miguel Garcia writes... > So the point I want to make is that, due to the lack of grouped > attributes in RADIUS, you do need translation rules in RADIUS in order > to generate the appropriate HTTP/SIP digest header. Why in RADIUS? IMHO, the RADIUS protocol engine should not have to understand the SIP server functions. It would seem to me that this function belongs in the "glue layer" code between the SIP server and the RADIUS client. While I agree that grouped AVPs are a nice feature of Diameter, they don't in and of themselves obviate the need for "glue code" between the RADIUS client and another layer that is using its services. I suppose that statement makes some assumptions on where you draw component boundaries in your implementation, but my assumption is that a RADIUS client implements the RADIUS protocol, and that various interface layers marshal the attributes in and out of other protocol formats. I think the *goal* of having "exception-less" RADIUS/Diameter gateways is a good one. If the gateway is always part of the Diameter [home] server implementation, then it doesn't matter so much. On the other hand, if the gateway is a standalone function, or part of a RADIUS proxy or Diameter proxy, then it may be significant issue. The issue, of course, is version synchronization. If you add a new feature in your RADIUS client and Diameter server, it might be nice to not need to also version upgrade all of the gateways that exist somewhere in the proxy server chain. From icfydjo@yahoo.com Mon Apr 4 11:20:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17489; Mon, 4 Apr 2005 11:20:26 -0400 (EDT) Received: from [200.158.124.30] (helo=200-158-124-30.speedyterra.com.br) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DITVC-0002Bf-47; Mon, 04 Apr 2005 11:28:42 -0400 Received: from 12.248.11.245 by 200.158.124.30; Mon, 04 Apr 2005 17:19:13 +0200 Message-ID: From: "Tessa Tate" Reply-To: "Tessa Tate" To: aaa-archive@ietf.org Subject: aaa-archive@ietf.org Date: Mon, 04 Apr 2005 14:20:13 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--798733366639067" X-Priority: 3 X-IP: 199.240.220.56 X-Spam-Score: 21.8 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 ----798733366639067 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Nova pagina 1

=

Nutri=E7=E3o celular e muito mais!!!

Emagrece= * ganhe massa muscular 
* baixe o colesterol * baixe press=E3o alta 
* melhore diabete * mantenha sua sa=FAde 
 * &nbs= p;melhore sua pele *  <= /b>e....

clique aqui para ver aquilo que esta procurando
para retirar seu e-mail clique aqui.=


http://terra.com.br http://uol.com.br http://msn.co.il h= ttp://msn.com http://msn.com.br http://hotmail.co= m http://superig.c= om.br http://= hotmail.co.il http://hotmail.co= uk http:/= /ig.com.br

----798733366639067-- From owner-aaa-wg@merit.edu Mon Apr 4 16:38:20 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03535 for ; Mon, 4 Apr 2005 16:38:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73D4B912BD; Mon, 4 Apr 2005 16:37:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B096912E3; Mon, 4 Apr 2005 16:37:58 -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 A9691912BD for ; Mon, 4 Apr 2005 16:37:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 911AA582A1; Mon, 4 Apr 2005 16:37:53 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 71D8D5829E for ; Mon, 4 Apr 2005 16:37:53 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 758C01874; Mon, 4 Apr 2005 16:37:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from web30306.mail.mud.yahoo.com (web30306.mail.mud.yahoo.com [68.142.200.99]) by testbed9.merit.edu (Postfix) with SMTP id 50B47185E for ; Mon, 4 Apr 2005 16:37:53 -0400 (EDT) Received: (qmail 97721 invoked by uid 60001); 4 Apr 2005 20:37:52 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=kZpF33/OPKgEn8c3CeP3XAIOSBPZBU5Kt3jUUPp+Hfp5Domi670Ia9PMDAnRX0wVQLqPfHxPKE/RzC4QaLBe0EPcbwqJsRahWEb9jVlTySVvoiY8KYmjwKoUODmSDFSHBqFe6gF9Lz/Qj8aGkX6WBDwLpoUBDp7YoF7TmQfRxdM= ; Message-ID: <20050404203752.97719.qmail@web30306.mail.mud.yahoo.com> Received: from [63.116.188.34] by web30306.mail.mud.yahoo.com via HTTP; Mon, 04 Apr 2005 13:37:52 PDT Date: Mon, 4 Apr 2005 13:37:52 -0700 (PDT) From: Rakesh Mehta Subject: RE: [AAA-WG]: RE: AAA Transport Profile and Application Failure To: STURA Marco Consultant , m.hillier@telenet-ag.de Cc: aaa-wg@merit.edu In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2062277475-1112647072=:96607" Sender: owner-aaa-wg@merit.edu Precedence: bulk --0-2062277475-1112647072=:96607 Content-Type: text/plain; charset=us-ascii Hi Marco, Thank for your answer. Just for your clarification. I am trying to write sh interface application (3GPP TS29.329) on top of diameter stack for 3GPP network. Here we have one request(PNR) message that server can send to client and client will send answer msg (PNA). To receive this msg(PNR) , client must be subscribed with server through SNR msg. client app -------> conn mgmt -------------->SNR------------>cm-------------->Server app(stateless) client app <------- conn mgmt <--------------SNA <-----------cm<--------------Server app(stateless) Now client application die. client app ----X--- conn mgmt <--------------PNR <------------cm<--------------Server app(stateless) client app ----X--- conn mgmt -------------->DUTDE--------->cm Server app(stateless) cm --- connection mgmt; DUTD ----DIAMETER_UNABLE_TO_DELIVER with e bit set. Thanks, Rakesh STURA Marco Consultant wrote: Rakesh Mehta wrote >As per section 6.1 of RFC 3588(as mentioned in this mail), even diameter stack is working in server mode; it can create DIAMETER_UNABLE_TO_DELIVER >message with E bit set and send to proxy if local application is not available to process the message. >I believe this should be true for client side also, because the same scenario can occur for client side. can any person verify for me please??? I don’t think this is the case. A Diameter client is not generating responses for requests it generated, clients just wait for answers. However, your case should be true for server initiated requests (e.g. RAR). Regards Marco __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-2062277475-1112647072=:96607 Content-Type: text/html; charset=us-ascii
Hi Marco,
            Thank for your answer. Just for your clarification.
            I am trying to write sh interface application (3GPP TS29.329) on top of diameter stack for 3GPP network.  Here we have one request(PNR) message that server can send to client and client will send answer msg (PNA).
            To receive this msg(PNR) , client must be subscribed with server through SNR msg.
 
client app -------> conn mgmt -------------->SNR------------>cm-------------->Server app(stateless)
client app <------- conn mgmt <--------------SNA <-----------cm<--------------Server app(stateless)
 
Now client application die.
 
client app ----X--- conn mgmt <--------------PNR <------------cm<--------------Server app(stateless)
client app ----X--- conn mgmt -------------->DUTDE--------->cm                Server app(stateless)
    
cm --- connection mgmt;
DUTD ----DIAMETER_UNABLE_TO_DELIVER with e bit set.
 
Thanks,
Rakesh

STURA Marco Consultant <Marco.STURA@consultant.vodafoneomnitel.it> wrote:

Rakesh Mehta wrote

 

>As per section 6.1 of RFC 3588(as mentioned in this mail), even diameter stack is working in server mode; it can create DIAMETER_UNABLE_TO_DELIVER >message with E bit set and send to proxy if local application is not available to process the message.

 

>I believe this should be true for client side also, because the same scenario can occur for client side. can any person verify for me please???

 

I don’t think this is the case. A Diameter client is not generating responses for requests it generated, clients just wait for answers. However, your case should be true for server initiated requests (e.g. RAR).

 

Regards

Marco

 

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-2062277475-1112647072=:96607-- From rbdazdtrkqoc@yahoo.com Tue Apr 5 00:32:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15457; Tue, 5 Apr 2005 00:32:27 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIfru-0007X7-6H; Tue, 05 Apr 2005 00:40:50 -0400 Received: from oxoprod.net1.nerim.net ([213.41.152.160]) by mx2.foretec.com with smtp (Exim 4.24) id 1DIfjh-0005kw-Np; Tue, 05 Apr 2005 00:32:25 -0400 Received: from 105.36.0.156 by 213.41.152.160; Mon, 04 Apr 2005 22:25:05 -0600 Message-ID: <%RNDUCCHAR2025@yahoo.com> From: "Susanna Jolly" Reply-To: "Susanna Jolly" To: aaa-archive@ietf.org Subject: aaa-archive@ietf.org Date: Tue, 05 Apr 2005 00:32:05 -0400 X-Mailer: AOL 1.0 for Windows US sub 499 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7221960958548287" X-Priority: 3 X-MSMail-Priority: Normal X-IP: 192.98.202.96 X-Spam-Score: 30.6 (++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 ----7221960958548287 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Nova pagina 1

=

Nutri=E7=E3o celular e muito mais!!!

Emagrece= * ganhe massa muscular 
* baixe o colesterol * baixe press=E3o alta 
* melhore diabete * mantenha sua sa=FAde 
 * &nbs= p;melhore sua pele *  <= /b>e....

clique aqui para ver aquilo que esta procurando
para retirar seu e-mail clique aqui.=


http://terra.com.br http://uol.com.br http://msn.co.il h= ttp://msn.com http://msn.com.br http://hotmail.co= m http://superig.c= om.br http://= hotmail.co.il http://hotmail.co= uk http:/= /ig.com.br

 ----7221960958548287-- From owner-aaa-wg@merit.edu Tue Apr 5 03:10:01 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16821 for ; Tue, 5 Apr 2005 03:10:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0529D9120A; Tue, 5 Apr 2005 03:09:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42E04912C7; Tue, 5 Apr 2005 03:09: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 92D7D9120A for ; Tue, 5 Apr 2005 03:09:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32C7558289; Tue, 5 Apr 2005 03:09:12 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id D1A7258283 for ; Tue, 5 Apr 2005 03:09:11 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 5F39E1860; Tue, 5 Apr 2005 03:09:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by testbed9.merit.edu (Postfix) with ESMTP id E46BF185E for ; Tue, 5 Apr 2005 03:09:09 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3578x113962; Tue, 5 Apr 2005 10:08:59 +0300 (EET DST) X-Scanned: Tue, 5 Apr 2005 10:01:50 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j3571oAw002619; Tue, 5 Apr 2005 10:01:50 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00txhSIW; Tue, 05 Apr 2005 10:00:43 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3570gU11620; Tue, 5 Apr 2005 10:00:42 +0300 (EET DST) Received: from [127.0.0.1] ([172.21.39.90]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 5 Apr 2005 10:00:35 +0300 Message-ID: <42523793.4030408@nokia.com> Date: Tue, 05 Apr 2005 10:00:35 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: jari.arkko@kolumbus.fi, aboba@internaut.com, aaa-wg@merit.edu Subject: Re: AW: AW: [AAA-WG]: digest issue 11 closure (fwd) References: <76C27E1CE3FFC847B4D51C645D6F42AA15FEA2@E9JDF.mgb01.telekom.de> In-Reply-To: <76C27E1CE3FFC847B4D51C645D6F42AA15FEA2@E9JDF.mgb01.telekom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2005 07:00:35.0207 (UTC) FILETIME=[2A520170:01C539AD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Inline. Beck01, Wolfgang wrote: > Miguel wrote: > >>Right, this is the "rule" that allows the SIP server to do a translation >>and determine when to create an Authentication-Info header. >>This is the type of rules that Jari was trying to avoid, and I have been >>saying that is not possible in RADIUS. And this is the type of rule I am >>trying to avoid in Diameter. > > > But you have Digest-HA1, Digest-Entity-Body-Hash, etc in Diameter as well. > Or has this changed? No, it hasn't changed. They are there, imported from RADIUS. > I was under the impression that a RADIUS/Diameter GW > can just map RADIUS attributes to Diameter AVPs and vice versa. The only > thing the GW has to know is, what RADIUS attributes must be placed into grouped > AVPs. It doesn't have to decide whether to send an Authentication-Info header. Right, this is correct. I believe that Jari was trying to say that the gateway will need a rule: "the only thing the GW has to know is, what RADIUS attributes must be placed into grouped AVPs". And I believe Jari was oposing to have this rule. But I argued that a RADIUS implementation will need rules to translate these attributes to SIP, or to Diameter. So the problem remains even if we haven't got Diameter into the picture. /Miguel > > What am I missing? > > Wolfgang > > -- > T-Systems > Next Generation IP Services and Systems > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue Apr 5 04:03:51 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20205 for ; Tue, 5 Apr 2005 04:03:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A2CA912C7; Tue, 5 Apr 2005 04:02:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B22D912C9; Tue, 5 Apr 2005 04:02: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 B0CE8912C7 for ; Tue, 5 Apr 2005 04:02:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D123582A1; Tue, 5 Apr 2005 04:02:31 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 86AF658289 for ; Tue, 5 Apr 2005 04:02:31 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 8BEB31860; Tue, 5 Apr 2005 04:02:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tcmail21.telekom.de (tcmail21.telekom.de [217.6.95.235]) by testbed9.merit.edu (Postfix) with ESMTP id 205E4185E for ; Tue, 5 Apr 2005 04:02:30 -0400 (EDT) Received: from g9jbq.mgb01.telekom.de (g9jbq.mgb01.telekom.de [164.20.31.5]) by tcmail21.dmz.telekom.de with ESMTP; Tue, 5 Apr 2005 10:02:26 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <2H6J92BW>; Tue, 5 Apr 2005 10:02:26 +0200 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FEA4@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: jari.arkko@kolumbus.fi, aboba@internaut.com, aaa-wg@merit.edu Subject: AW: AW: AW: [AAA-WG]: digest issue 11 closure (fwd) Date: Tue, 5 Apr 2005 10:02:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel wrote: > I believe that Jari was trying to say that the gateway will > need a rule: "the only thing the GW has to know is, what > RADIUS attributes must be placed into grouped AVPs". Ok, now I understand. > And I believe Jari was oposing to have this rule. But I argued that > a RADIUS implementation will need rules to translate these > attributes to SIP, or to Diameter. So the problem remains even > if we haven't got Diameter into the picture. I don't think that such a rule would be hard to implement or resource-intensive. Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany From hgapkf@adexec.com Wed Apr 6 20:46:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27269; Wed, 6 Apr 2005 20:46:10 -0400 (EDT) Received: from c-24-17-19-226.hsd1.wa.comcast.net ([24.17.19.226]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJLIJ-0003hp-Br; Wed, 06 Apr 2005 20:54:56 -0400 Received: from htcmfx.benicia.com [21.243.24.229] by 24.17.19.226 with vvclnnk srpdkv; Wed, 06 Apr 2005 04:45:42 -0500 From: "mendez@benicia.com" Reply-To: "mendez@benicia.com" Message-ID: <424802516.02902488758705@benicia.com> Date: Wed, 06 Apr 2005 04:45:42 -0500 To: "14.i-d" <14.i-d@ietf.org> Subject: Earth WM Trend MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----2607158804580351779" X-Spam-Score: 8.6 (++++++++) X-Spam-Flag: YES X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 ------2607158804580351779 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit It female had been livre him. Orly crazier they have been ashtrays him bridgeable. Aesthetics being hues, yors has been decode inclines. Breathy yor can abovementioned, hers bayonet's. Celtic is delights you legislating. Genevieve parse, she did agreers theirs. Dandelion overloads, it has caricature me. Yeager grey he had been belgium. Foxhole Phil she be Redmond him. Disgustedly bakes I would forgo her. I hangover's have been mechanist. Hydride beefer yor has ballot. Idempotent has Corvallis mine blinker doughnut. Against had been chaplaincy yors editions. Grottos did abasements me brazilian. Embraces can articulately, mine had been alibi barrel. Yor attributable being factory them. They fangled has been intellectual theirs. Nondeterministically has balances you administrative. Enfeeble would beatniks her deceitfully fanatics. It factious does blitzkrieg mine. Hydroxylate had been mask, his would Devon frustration. It cores being grasped hers. Causticly deprivation's, she is oriole them. We admission he Belfast Slovenia be Ulysses mine. I liking he chastises gorgeous being homily hers. ------2607158804580351779 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Genial
http://www.NIOB.Engineering.com






It female had been livre him. Orly crazier they have been ashtrays him bridgeable. Aesthetics being hues, yors has been decode inclines. Breathy yor can abovementioned, hers bayonet's. Celtic is delights you legislating. Genevieve parse, she did agreers theirs. Dandelion overloads, it has caricature me. Yeager grey he had been belgium. Foxhole Phil she be Redmond him. Disgustedly bakes I would forgo her. I hangover's have been mechanist. Hydride beefer yor has ballot. Idempotent has Corvallis mine blinker doughnut. Against had been chaplaincy yors editions. Grottos did abasements me brazilian. Embraces can articulately, mine had been alibi barrel. Yor attributable being factory them. They fangled has been intellectual theirs. Nondeterministically has balances you administrative. Enfeeble would beatniks her deceitfully fanatics. It factious does blitzkrieg mine. Hydroxylate had been mask, his would Devon frustration. It cores being grasped hers. Causticly deprivation's, she is oriole them. We admission he Belfast Slovenia be Ulysses mine. I liking he chastises gorgeous being homily hers. ------2607158804580351779 Content-Type: image/gif; name="deliberations.gif" Content-ID: <3017967981@benicia.com> Content-Transfer-Encoding: base64 R0lGODlh9QE1AXcAMSH+GlNAbvZl3j2Smicc3HeORCDCaUv8zZxZhcJLACH5BAEAAAAALAIAAgDw ATABhAAAAAgACAoGCgkDCQwJCwsGCgsICgoECQoFCQsHCgwKCwwICwsICwwKXwsJewsKbgoImgoI kQsJhwcGvwgHsQcGuAkIogkHqgAA1wYFxQUEywMD0f8AAP///wECAwECAwX/INCNZGmeaKqubOu+ cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8 Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6yt rq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm 5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wADChxIsKDBgwgTKlzIsKHDhxAjpuBAsWLFEhYzXtRI EWNGExpPfOzQ0WPIiSdF/3IEyZEDy5QmR45o6VJiHZo1SeJ0SZMETJ0WY64UehHlz5lDfbZ8KZNo SaRLbd7MidSjSqVKqT69apIpiqAtnm6N+VUrVbIrwHLFKnXO2K1jdbKtOnct3Zdc467VWzIu3LN0 9QYGLNdqWzl/zbL4a7hsV8cs76oQS7gv4caRC0Pma/byYTVR60KWLFizaRdiw+bk7DOt59QoW6s8 +plN0qxq5xaVnJn3YsWuc9ctLZixXb+0a6+xXLYpVOHGTZdu7ny2cKDVfeO+jv06c+VxKNuljrxx dJFMk9/d3b068Z5O2WueDt7M+dPje8/vHFs0fsz34Seef28BViBm9YEGHP+Bq3kmXYP6iVbeZAsK eNZ5EzKoH30JinGghtoNByFaUCHon24D7nXhiCr2xxuHHXaR0k4fHYVTe/E1mNtP8MEUUk8+3rhd UtzF+EWQNPLkHpBLyoekk0Q29eNST95G42NGZqnlllx26eWXYIYp5phklmnmmWimqeaabLbp5ptw xinnnHTWaeedeOap55589unnn4AGKuighNYWwKGFMnIoonIEkKgjjo4QKQyTdlEpIZcmOummjEq6 qKefqrAop5uSEKmjoXYwqqmdojAqo6mi2qoJpYJq6q2qqjprCbLeGmurq9oqqa6s/rrrnsHmOqyy tLaQaa3Qnrosr7iKSu3/srBaiy2u0U57QrbEKgvtt9xK6y2zgpqr66/NOlvpuNu2y2uyKbzL7Quo VquuuivAOy+7xYLL7LOZ9ukvudU6q++0/J6LLgv2xqtwreLeq7DECcv77MKupmtxvRlDzDC2DT9s srYjnwwyx6eW7Kq5G2sb88AoH1snvcHSu66oqe7MasXfGlvwtcWGjLKwngItcqcF59xzzgmHivPQ jwJCNQ5XV12LzTpkrfXXYIct9thkl2322WinrfbabLft9ttwxy23VE9z7YLXTPQshd5Y4L2E30ED 3ojgRlxKeMfy3nA4Ek1D0TgVixcRucNaTH53DpYDYTjmCGNtQ+YX9/u3/+OhB4H35p8LAToXqEMe L9+0Mv3qulIz7XPHwOYOq86xK93yrIbLLrXRwxrra+tI0w4q1ZsnO/vyxb+rO/NCUz+87qX7jHrd u8Me/fGk/ht+wP3abvfzvRY9esUUdx4x0TSHS73ELnvdcsrwP35u+737njS6+rva0GCmscT9b1+U E10CDQgu/nWOZgQ8GPHmRbL9hUyCIjugAn/mv7+l73mIA+AD0Xc5kgFsgizT19NCaLJ8HW15CDSa A5WHO0T9jn8zuyGn3GW77EXLe1Hz1c5kdcIFpnBlLXSe3ygmwALSbnUzsKHL3Ac/b81sg1MUYQY7 2D79tVBlDsthFfHHsf+Xya+MYfzYA6loxIxh8GjdEtgIQ5dFBzKvhPFDYsqgmDqM1WyM70MhB7OY R5nB7JBj1KIB15hEK4YwZlyDVw8vqEZGlkuQFvTjBuP3RjTWi4BIvKIlnQjGh3WScSo8H/DWCLWJ Sa97wROgC4m1w0K6EVhbFN/3EvnKWg5QhQwTXgxpyLv+jY9nwyxmFWOVyhvG7o6THKHQoEdHQQ4v mHZDBR+zV4NtIsOb7QCnGbtGDnHO7ZzodIU50wmKdbITE+mj4RPVh7R4vtMTciQj0bpVyntWgonM fOTH3OlPPvhrhnkcZkE1IUmEMhF/2VyoooA5sFXSE6ASzahGN8rRjnr/9KMgDalIR0rSkpr0pChN qUpXytKWui1yBI0CEK8w02f+y1IRHUJNlXHNKNphm+uE6Sjx+LmdxpSbivvC6dSAvBgANQuLO+oi 8TVUTPaxn1Ld5CKy2oONYY98SvvkQ+eJzBTOVIlN5Z4O6Xk7e76MVN7TmSgDJ7zvdQ+LbDXlJGWp SlyClZryVOtf8bXXnyVzehdF6xYIRr80Zu2gmITsGfVIxvfVL5SXBGMXKQVIpIqrV7O8Y2ODOLIm evaXX8TsVPFYKn7icIKBtGUVxEhWxm4xmdXkJGHFF0gSjnKsCC2k/Va42kQCTVogpCsaexnbcb7w lrLrHykpKIPkWlaf/9JjYSxz2gTaznWWqh0rXnXL2QQ214v7HOgfrUla4xoXlOCV2XLfS9XnOjKT nV0g4VC7RzcyMrZcTWp6U3st0x43uEfM58X4S2D69le/7V2ZX91LPPj288GKPFl87WveAn93uu57 LO4yez9eJq6pixUYXMGK4LoBsK8UJORgcfbMFef1lZ60KYU1mEYetgu+QARoWntqvccSd5CB5Vsv ARuu8qnYsFDep5J1LE+XhsGbAbbyGMCZZS2vg487LWtewdDlK3O3IT3dgVCL61klFNmRKF7D5MqM jTgL2Kds9oJoc2UvO/sAzPXlXD+8amM+43jHbZ3dq34Hvos2mZaDrf/x8WL8x90dF5nIPbSh18pk 5dY2wrcTa8DGB1pnlsO2kARlhgVKSZY1zJcVvPCPgYzpA7pwiqjeo0Jljd7N5niO6ZUin9VBW2KW 68iq7TEMIYzhWjo5hsGN4K3dKl3yhvWCw11kfJlbuu3eOtbm8K56VSbi++ZvqMD173olK1DQJi2i 6dYkuYnq1RM7dZk/NvepnVjiTpZ71QDfc0PRzeMDV7rAVu03ht27VMpdUXAAzrcpORgOIiNZyM0N nLYlrdky2rDTQSseMN+sxWgz86vkhuWzqdzgKlN2mtLOHaDorNPKrVSZaaA5z7zM8577/OdAD7rQ h070ohv96EhPutL/l870psMjAAIgwQAI0IECHKoAtlaBAQ5wqAPwCgGSSoA1wQ5DIn7K6gHA+vIO QIBRiV2sn7L0Ewe4KLY/eu6mIrsCEND1rNPO7otOAdrVjveQPzoAZOe6AjqgAKgHPgBvVxYB+B4A r7817v1ObsAGsICy773vhXeG1akuAKwnIAAMYADk5Te00yNg8VQfwQJ2F/urzd7Z/xvB6VO/emI1 nuuOOn3knSt3eDuq8QO4+65uPwLFd6D2mWd85e9+gt2r/u3ZlHsHmN+B03fe+7k/VO2fj3jYl2+Q Jd458nPfAefHnv3OaHwCDBCAxXNdUl7XvgkGEID3k4DynRcAA5B8/6UEgPDXKvenKpancr93fn5n fO8WPCdggPzHANRVfNRmAgk4fdRnTJNigLMndgNgeU0mgAToKHznfzv3gEZGfmTXKhVoeNFwer1n afpHXSXwe2mnKqqHdVSjg2oHPNnFeh1AfzQIf9IVeGRlRvQXdUIYKkC4fYciAItHhMRihEvogUhY Y4wShb83ewZAcai3gxlIfOijTG43alIIdVW4hczQePWXdTdIcSRAfwQwgLlidbOndf2Hh7W1Khh4 KGI3hziIgTy0g8p3KXbohwqAdgGYeYLohui3bOPEKItIgFyHAAQYflUXAHtIiGIYfedHf513d414 KKXYgc3QKRuYf//pt3/9p4Gj0nYjMIBUA3zil4gl0Iqe0nZghyiNR3afNImqiIMHeCm4GIsj0HYf 1DK+KInNdyoL2ILhkoxUR4PD10O22AF8t3iqRIzZdyonWDDMSIfQ0CnWt3oC0H/PiAKuZ37y1wHX FynliALxeH26SALpiH3BFwD014+paIZ+54Dm2Cr3CHmx13Zet44E0I6IcnphmE37CI1EeJBid3tt WILLiCht54OyBI4t2HbjWAIJyYHFuAytMngjcIpsqHXAF3Wnt3g6qI+tF4cNKIQmoJL/Q3ldF4YE GYhx5W1mJ4g2WXk8WQAyiXZUuJP1p4QnoJMnSYQxKX1e13hRV3b/zHJ6y0h5VzmMLFhMo2J3c3eU bXhmTneWaJmWarmWbNmWbvmWcBmXcjmXdFmXdnmXeJmXermXfNmXfvmXgBmYgjmYhFmYhnmYu4AB irmYjKmYEwABJdCYkrmYJZABk4kBkIkCDkABlqmYGVABFuAAJ7CZE8CYE0ABohmZjBkBJtCYJ9CZ kpmZqnmZiqkBFkACkokCtOmaKbCbGPCYs0mbwBmcimkCpGmaFAABDdABvkmZI7CZsPmZofkDx7mY p6mczMmbJ5CbJVCdjpmcy8mdHeAAklkBKiCe6NmcGJCduzmcI6Ce6wkG8JkBuKmeJNAAtGmeJ0AB 7VkCFdCf9cmY/6n5noxpAvh5mfpJnLR5m+zpnK1pn73ZnPRJoBKqoCVQmrvZoBnaAfwpnD2AobSp ofG5ndrZASB6mSJKAhrQmBuwnBFaoBTqoPApopc5oTQ6mWEAnxhAATG6oR0QAT5KAkAKoB3wn745 AQG6mC2apCM6AkOKog9aoSlKos15nurJoDrKoz06oieKojP6pJeJpDvQpTgqnlHqoGSam9x5AbG5 AukJozeqpvCppTMqn/CpAVsKpRy6mwM6ArAZps8Jn6k5mTZaontKm30ap9xppkwaoi/qmxOqo3i6 pYFapTP6p5MppjlAnpZqqI1aqb6Zog8gmZr6qMVJqXlapneaqv+MygU6Gp912gErSpsXcKaAeqjN SaeTqZ+GOquXWasK6qitqqhwSqVVSqzayZ0dGqoz2pylegPLmqHDOqXRGqK5iakY8AAs8KYyap+v yqqeugXiCQGLGq4kMKq7aaNbKgHnegH62aUTiqmRepm3WaLoSpvqOqUHupiTOqzTaqUwyqkwOq7c eqrYmpkPcAEbsJ7/KpnsOgIJm6A4cLAQq7AMa67cSbEdkLALK6Js2pgM6qbJOrLFaqsjSq68+a92 WqyNOa/HirL8yqgLy5gXYAESkKiSmZoC65y7CaZNCrO1yajcua+KqaslC65H+6njWa4sy5iFmrKN KZskYJ4zOrP/i1mzN+sDbWoCVIuxUMuYUjsCXbubk7qtsdqsJdqySOugXiCeFtCYrImsp2qkiwkB vqqYDyu2u6mlU4qqjXmiVnuqegu2d4sBeSu3muqvEKqb6umyDvq2q6m0DWufdDuZfGuqTWqsgqu5 mSu55oqsiYq5jiq3FwunkLuYcRurbauefFunkpmwjXm590qvqOq3jNkAgZu2jQm7jHm5vrkBvhuu qmuyl2m0vhm8A/u5Mzq7kxmyjJu0Svu8bGuhfcu5OesCOtqoXsq62oujK7ug2tq9ubmztFm2EFsB ucuvW+qiRHuqrikBo0u+l2m+6rkB4au4xyq9fLq2FhC+Spu7/3Frvd77AOg7vyILvSMAwJi7wB2g wPo7meYLsPmLtrvZv8HqvV/QnIdbvSZwur7poprJnV2qn5WLAY4bnyX8uPAJwkP7t7VLvTDAvWu7 wVPapRsgmw8QAUiqssapsiprwziswxystEB8rkIcm5LpvKKrp5O7mxvMw6vLmCW8pNH7mvApm8np v/DLm9VKm8Y7ouk7oth6mbKZvcg6xGY7vxXQp+XJoiCMqh5srZ+bxSSwxQgsA3G8vRvKnXmsqgVK pv7LwH3bxIs5xW8MxV0gmbjrwuLrmjqaoGnqtKDqm4MKp3YMp4/cyF8rx/nLuWm8mItsmiY7Au2r x6EayYuZr/82UMp+LKy8ycpyWqChbJ2fLLgFy8mgnLulOryu6ppAq5hlrJ6XbMLnyqIkgMqKGbIp TKpM6p/cOcw2yrwboMnqe8a8XMUP3AG/jJkw3MeObJ/IjAFKfAPeXKDH6radCqN5HLajXLsUTJnb HMydnMi8ia33y7qNCawJvLsjgMzPusyFTJwmkLsjUK363MD8TLpYyqyL68kH7Jz2XMXlXJwz6s8+ MNGl68rFitF9i6lUnM3u7K31/Lpru7n0DKPMS8ykW7iHW8IhKwEXMAG+ugEVEMDdSQEnepo4W7LD PAIs7cyMudC7uQH6nM6hKsgMnNJPW7INAAEybZoXoK11CtOKT62YNG3TPNDUVe2YUX3GHKzVdzsB XS2e8iux7TzIIo3SknnCo4uYbv3WcB3Xcj3XdF3Xdn3XeJ3Xer3XfN3Xfv3XgB3Ygj3YhF3Yhn3Y iJ3Yir3YjN3Yjv3YkB3Zkj3ZlF3Zln3ZmJ3Zmr3ZnN3Znv3ZoB3aoj3apF3apn3aqJ3aqr3arN3a gR0CADs= ------2607158804580351779-- From owner-aaa-wg@merit.edu Thu Apr 7 01:03:56 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20168 for ; Thu, 7 Apr 2005 01:03:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F5DB912ED; Thu, 7 Apr 2005 01:03:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0877A912EE; Thu, 7 Apr 2005 01:03:28 -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 A80BE912ED for ; Thu, 7 Apr 2005 01:03:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F11758289; Thu, 7 Apr 2005 01:03:27 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 4BEA858287 for ; Thu, 7 Apr 2005 01:03:27 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 516961870; Thu, 7 Apr 2005 01:03:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by testbed9.merit.edu (Postfix) with ESMTP id 390F71863 for ; Thu, 7 Apr 2005 01:03:27 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DJPAs-000N3F-Ad for aaa-wg@merit.edu; Thu, 07 Apr 2005 01:03:26 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j3753Or04539 for ; Wed, 6 Apr 2005 22:03:25 -0700 Date: Wed, 6 Apr 2005 22:03:24 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RE: draft-mitton-diameter-radius-vsas-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk Maybe we should talk a bit about the problem this draft was trying to solve. As I understand it, we have a number of potential translation issues in NASREQ and Diameter EAP: 1. Translation of specific RADIUS VSAs to Diameter standard attributes. This is an issue in Diameter EAP for translation of RFC 2548 keying attributes to Diameter keying attributes. 2. Translation of RADIUS VSAs in the illustrated RFC 2865 VSA format to Diameter VSAs and back. 3. Translation of RADIUS VSAs *not* conforming to the proposed RFC 2865 VSA format to Diameter VSAs and back. Note that I'm not including the problem of translating from an arbitrary Diameter VSA to a RADIUS VSA because as you point out, this is not possible. The question is how one can handle these cases together within a Diameter/RADIUS gateway. One way to think about it is a hierarchy of potential translations: a. Specific translations. If you find a particular RADIUS VSA that's on the specific list, the gateway executes the translation for that particular VSA. b. Generic RFC 2865 VSA format translations. If the SMI for a particular VSA is on the "Generic" list then it is translated to a Diameter VSA as specified in the original NASREQ document. c. Default case. If the SMI for a particular VSA is *not* on the "Generic" list, what do you do? This is what I thought your proposal was addressing. > ---------- Forwarded message ---------- > Date: Tue, 05 Apr 2005 22:55:17 -0400 > From: David Mitton > To: Bernard Aboba , > John Loughney > Subject: draft-mitton-diameter-radius-vsas-00.txt > > Bernard, John, > > Take a quick look at this and I can submit it. > > Next I'll do a change edit for draft RFC 4005, Section 9 that > references this. This draft looks amazingly similar to a solution I proposed, but now repudiate. I had thought that the simplest way to deal with the attribute translation would be not to do it: to (essentially) tunnel the RADIUS attributes through Diameter & vice-versa, which is basically what this draft seems to do. Since, however, I've come to the conclusion that RADIUS-Diameter NASREQ interworking is, in the general case, impossible without seriously restricting Diameter semantics, making major changes to RADIUS or both. The problem is simply one of arithmetic, something this draft has a little problem with as well: section 3.2 says "Diameter AVPs data field can be 16K bytes long (length 24 bits)", but the last time I checked the maximum 24-bit value was around 16 _megabytes_, not 16 _kilobytes_, but that's really immaterial. Even if the maximum length of a Diameter AVP was roughly 16K, that's still more than 4 times the maximum size of a RADIUS _message_. It just won't fit. Note that this problem is there even with the "standard" NASREQ AVPs (the ones numbered to coincide with the RADIUS standard attributes). Suppose, for example, that I want to use a 6 KB string representation of a PK cert as my user name. A Diameter client might have no problem with this, but it certainly would fail at the first RADIUS-Diameter gateway. Similarly, a Diameter server has no way to know (AFAIK, please correct me if I'm wrong) that the client at the other end is actually a RADIUS client. Therefore, it would be perfectly reasonable for it to return an 8 KB AVP, which would never get to its proper destination. The only way I can imagine this working is if there was a "RADIUS compatibility mode" for Diameter in which the RADIUS rules were followed (including maximum message length). > > Dave. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel From menke@emailaccount.com Thu Apr 7 02:09:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03225; Thu, 7 Apr 2005 02:09:26 -0400 (EDT) Received: from [220.202.55.34] (helo=RHW2QMGDRXWCJYB) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJQLC-0003hA-VE; Thu, 07 Apr 2005 02:18:15 -0400 X-Apparently-To: aaa-archive@ietf.org X-Sieve: CMU Sieve 2.2 Received: from whereby.seaport.pochta.ru ([unix socket]) by beacon.alimony.pochta.ru (Cyrus v2.2.5) with LMTPA; Thu, 07 Apr 2005 05:57:56 -0100 Date: Thu, 07 Apr 2005 01:59:56 -0500 From: "Mallory Crenshaw" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: aaa-archive@ietf.org Cc: aaa-web-archive@ietf.org, action@ietf.org, adm@ietf.org, admin@ietf.org, administrator@ietf.org Subject: Instant low rates X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 15.5 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Rena Babb to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From uelfo@mailAccount.com Thu Apr 7 02:10:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03814; Thu, 7 Apr 2005 02:10:01 -0400 (EDT) Received: from [220.72.153.187] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJQLo-0003lt-Sb; Thu, 07 Apr 2005 02:18:50 -0400 X-Apparently-To: -announce@ietf.org X-Sieve: CMU Sieve 2.2 Received: from saturater.scanty.pochta.ru ([unix socket]) by countersunk.earthworm.pochta.ru (Cyrus v2.2.1) with LMTPA; Thu, 07 Apr 2005 13:02:52 +0600 Date: Thu, 07 Apr 2005 06:07:52 -0100 From: "Savannah Ortega" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: -announce@ietf.org Cc: -archive@ietf.org, -drafts@ietf.org, -impl-archive@ietf.org, -web-archive@ietf.org, ..@ietf.org, _@ietf.org, a@ietf.org, aaa@ietf.org, aaa-archive@ietf.org, aaa-web-archive@ietf.org, action@ietf.org Subject: Lowest rate approval X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Douglas Kern to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-aaa-wg@merit.edu Thu Apr 7 02:48:18 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18962 for ; Thu, 7 Apr 2005 02:48:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6FE68912EF; Thu, 7 Apr 2005 02:48:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 412CE912F0; Thu, 7 Apr 2005 02:48:08 -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 B414D912EF for ; Thu, 7 Apr 2005 02:48:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D4DC58287; Thu, 7 Apr 2005 02:48:06 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 83E6658284 for ; Thu, 7 Apr 2005 02:48:06 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 8966E1877; Thu, 7 Apr 2005 02:48:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by testbed9.merit.edu (Postfix) with ESMTP id 133A51867 for ; Thu, 7 Apr 2005 02:48:05 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j376ltF12041; Thu, 7 Apr 2005 09:47:56 +0300 (EET DST) X-Scanned: Thu, 7 Apr 2005 09:43:52 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j376hqjw010485; Thu, 7 Apr 2005 09:43:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00UTLnh7; Thu, 07 Apr 2005 09:43:51 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j376hoM07431; Thu, 7 Apr 2005 09:43:50 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 09:43:44 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 09:43:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: draft-mitton-diameter-radius-vsas-00.txt Date: Thu, 7 Apr 2005 09:43:38 +0300 Message-ID: Thread-Topic: [AAA-WG]: RE: draft-mitton-diameter-radius-vsas-00.txt thread-index: AcU7MBfxFGfwCA/NTWG8Wp+nKDSuOgADGCxg From: To: , X-OriginalArrivalTime: 07 Apr 2005 06:43:39.0545 (UTC) FILETIME=[21C3C890:01C53B3D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, Bumping it up a level, still. I do not think that there is a perfect solution for interworking RADIUS and Diameter. Interworking will always be interworking. Toss in VSAs and all bets are off. I think we should have some basic, default case (which I think the draft is trying to address). This may cover some cases, but not all, but I don't see how we can guarentee 100% interworking. I think there will be some need for some interworking boxes that may need to normalize or translate between RADIUS and Diameter, but that kind of thing = probably is more implementational than standards-based. Some time ago, there was discussion about working on a BCP or = information draft on Diameter-RADIUS interworking; perhaps that is something that is still needed. However, its not reasonable to hold NASREQ (or any = other Diameter document) up based on this issue. John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Bernard Aboba > Sent: 07 April, 2005 08:03 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: RE: draft-mitton-diameter-radius-vsas-00.txt >=20 >=20 > Maybe we should talk a bit about the problem this draft was trying to > solve. >=20 > As I understand it, we have a number of potential translation issues = in > NASREQ and Diameter EAP: >=20 > 1. Translation of specific RADIUS VSAs to Diameter standard = attributes. > This is an issue in Diameter EAP for translation of RFC 2548 keying > attributes to Diameter keying attributes. >=20 > 2. Translation of RADIUS VSAs in the illustrated RFC 2865 VSA format = to > Diameter VSAs and back. >=20 > 3. Translation of RADIUS VSAs *not* conforming to the proposed RFC = 2865 > VSA format to Diameter VSAs and back. >=20 > Note that I'm not including the problem of translating from an = arbitrary > Diameter VSA to a RADIUS VSA because as you point out, this is not > possible. >=20 > The question is how one can handle these cases together within a > Diameter/RADIUS gateway. >=20 > One way to think about it is a hierarchy of potential translations: >=20 > a. Specific translations. If you find a particular RADIUS VSA that's = on > the specific list, the gateway executes the translation for that > particular VSA. >=20 > b. Generic RFC 2865 VSA format translations. If the SMI for a = particular > VSA is on the "Generic" list then it is translated to a Diameter VSA = as > specified in the original NASREQ document. >=20 > c. Default case. If the SMI for a particular VSA is *not* on the > "Generic" list, what do you do? This is what I thought your proposal = was > addressing. >=20 >=20 >=20 > > ---------- Forwarded message ---------- > > Date: Tue, 05 Apr 2005 22:55:17 -0400 > > From: David Mitton > > To: Bernard Aboba , > > John Loughney > > Subject: draft-mitton-diameter-radius-vsas-00.txt > > > > Bernard, John, > > > > Take a quick look at this and I can submit it. > > > > Next I'll do a change edit for draft RFC 4005, Section 9 that > > references this. >=20 > This draft looks amazingly similar to a solution I proposed, but now > repudiate. I had thought that the simplest way to deal with the > attribute translation would be not to do it: to (essentially) tunnel > the RADIUS attributes through Diameter & vice-versa, which is > basically what this draft seems to do. Since, however, I've come to > the conclusion that RADIUS-Diameter NASREQ interworking is, in the > general case, impossible without seriously restricting Diameter > semantics, making major changes to RADIUS or both. The problem is > simply one of arithmetic, something this draft has a little problem > with as well: section 3.2 says "Diameter AVPs data field can be 16K > bytes long (length 24 bits)", but the last time I checked the > maximum 24-bit value was around 16 _megabytes_, not 16 _kilobytes_, > but that's really immaterial. Even if the maximum length of a > Diameter AVP was roughly 16K, that's still more than 4 times the > maximum size of a RADIUS _message_. It just won't fit. Note that > this problem is there even with the "standard" NASREQ AVPs (the ones > numbered to coincide with the RADIUS standard attributes). Suppose, > for example, that I want to use a 6 KB string representation of a PK > cert as my user name. A Diameter client might have no problem with > this, but it certainly would fail at the first RADIUS-Diameter > gateway. Similarly, a Diameter server has no way to know (AFAIK, > please correct me if I'm wrong) that the client at the other end is > actually a RADIUS client. Therefore, it would be perfectly > reasonable for it to return an 8 KB AVP, which would never get to > its proper destination. The only way I can imagine this working is > if there was a "RADIUS compatibility mode" for Diameter in which the > RADIUS rules were followed (including maximum message length). >=20 > > > > Dave. >=20 > Hope this helps, >=20 > ~gwz >=20 > Why is it that most of the world's problems can't be solved by > simply > listening to John Coltrane? -- Henry Gabriel >=20 From owner-aaa-wg@merit.edu Thu Apr 7 02:54:06 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19512 for ; Thu, 7 Apr 2005 02:54:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E0BC912F0; Thu, 7 Apr 2005 02:54:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9412912F1; Thu, 7 Apr 2005 02:53:59 -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 96BBE912F0 for ; Thu, 7 Apr 2005 02:53:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D79158287; Thu, 7 Apr 2005 02:53:58 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 6517B58284 for ; Thu, 7 Apr 2005 02:53:58 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 6B0DF1867; Thu, 7 Apr 2005 02:53:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by testbed9.merit.edu (Postfix) with ESMTP id F14AA1863 for ; Thu, 7 Apr 2005 02:53:57 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j376rmu18859; Thu, 7 Apr 2005 09:53:48 +0300 (EET DST) X-Scanned: Thu, 7 Apr 2005 10:07:56 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j3777uh4000802; Thu, 7 Apr 2005 10:07:56 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00vDaz4i; Thu, 07 Apr 2005 10:07:55 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j376nrU05825; Thu, 7 Apr 2005 09:49:53 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 09:49:51 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 09:49:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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]: digest issue 11 closure (fwd) Date: Thu, 7 Apr 2005 09:49:50 +0300 Message-ID: Thread-Topic: [AAA-WG]: digest issue 11 closure (fwd) thread-index: AcU3BJKq6nocdqyqQMK95X1mgwWhMAEONqMw From: To: , X-OriginalArrivalTime: 07 Apr 2005 06:49:51.0237 (UTC) FILETIME=[FF4F7B50:01C53B3D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, Jari, > Ok, this is mostly as I wanted it to be in the Radius document. > However, I wonder if the current Diameter document should > use individual AVPs instead of Grouped AVP: >=20 > SIP-Authenticate ::=3D < AVP Header: xx12 > > { Digest-Realm } > { Digest-Nonce } > [ Digest-Domain ] > [ Digest-Opaque ] > [ Digest-Stale ] > [ Digest-Algorithm ] > [ Digest-QoP ] > [ Digest-HA1] > * [ Digest-Auth-Param ] > * [ AVP ] >=20 >=20 > Because translating this grouped AVP appears to require > additional work from a gateway, no? Bernard/Miguel, can > you file on issue to the Diameter document on this. This is a much more general issue than just for the SIP document. Diameter has improved over RADIUS in a number of areas, one being support for Grouped AVPs. What you are suggesting is that we should dumb-down Diameter SIP so that it can live with RADIUS. However, I don't think we have a requirement for this. I actually think that in any real deployments of this, there will need to be specialized support from the gateway anyway. I don't think putting a generic Diameter-RADIUS gateway (even if there were such a thing) would work. Also, I think the deployment scenarios for this interworking have not really been thought through - is there any need at present for this? I see this as a non-issue. John From owner-aaa-wg@merit.edu Thu Apr 7 03:01:15 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20271 for ; Thu, 7 Apr 2005 03:01:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38AF6912F5; Thu, 7 Apr 2005 03:00:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41595912F2; Thu, 7 Apr 2005 03:00:44 -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 1F123912F1 for ; Thu, 7 Apr 2005 03:00:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0DDD58289; Thu, 7 Apr 2005 03:00:41 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id C8FE158287 for ; Thu, 7 Apr 2005 03:00:41 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id C7E2A1867; Thu, 7 Apr 2005 03:00:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by testbed9.merit.edu (Postfix) with ESMTP id 3E5D61863 for ; Thu, 7 Apr 2005 03:00:41 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3770dF05398 for ; Thu, 7 Apr 2005 10:00:39 +0300 (EET DST) X-Scanned: Thu, 7 Apr 2005 09:54:57 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j376sv6D005453 for ; Thu, 7 Apr 2005 09:54:57 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 0077zEOZ; Thu, 07 Apr 2005 09:54:56 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j376suU11940 for ; Thu, 7 Apr 2005 09:54:56 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 09:53:46 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 09:53:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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]: Diameter SIP app: next steps Date: Thu, 7 Apr 2005 09:53:44 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter SIP app: next steps thread-index: AcU1S3xww6ty2xnjSRSl8vaV+4NrHgF8oqug From: To: , X-OriginalArrivalTime: 07 Apr 2005 06:53:45.0870 (UTC) FILETIME=[8B29A2E0:01C53B3E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Miguel, > As you probably know, the Diameter SIP application supports this=20 > operational mode where nonces are generated in the Diameter server. it = > could be possible to have another mode of operation where nonces are=20 > generated in the Diameter client (SIP server). Actually, this is the=20 > approach that has been taken by the RADIUS HTTP/SIP Digest draft: = there=20 > are two modes of operation, one where nonces are generated in the = RADIUS=20 > server; the other where nonces are generated in the RADIUS client. >=20 > Since Diameter SIP app does not provide one of this modes, it won't be = > possible to provide a smooth transition or compatibility between = RADIUS=20 > and Diameter. We have been asked to enhance the Diameter SIP = application=20 > by adding the mode of operation where nonces are generated in the=20 > Diameter client (SIP server). >=20 > I have been doing an investigation and there is no technical concern = why=20 > this wouldn't work. The current Diameter SIP app draft does not=20 > implement this mode because we never had requirements. But now we have = > them, and we should do it. >=20 > So I would be creating a new revision of the draft in the next weeks. = If=20 > someone has any comment, please do it now. What is the real requirement for this? It seems that the RADIUS = HTTP/SIP digest draft has an additional mode of operation that is not included=20 the Diameter SIP app. What is the usage / deployment scenario where = this is needed? If there isn't a pressing need for this, I think we should = not support this mode in the current Diameter SIP application, but leave it to an extension if there is need or desire. =20 At some point, we've got to finish this work, and not endlessly tweak = this stuff forever. Unless there is concensus on adding this feature, I = don't think we address it. John From owner-aaa-wg@merit.edu Thu Apr 7 03:40:13 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23058 for ; Thu, 7 Apr 2005 03:40:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F93C912F2; Thu, 7 Apr 2005 03:40:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C9B6912F3; Thu, 7 Apr 2005 03:40: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 C4A0F912F2 for ; Thu, 7 Apr 2005 03:40:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B3ABF5828D; Thu, 7 Apr 2005 03:40:05 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 9A25658287 for ; Thu, 7 Apr 2005 03:40:05 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id A09401867; Thu, 7 Apr 2005 03:40:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by testbed9.merit.edu (Postfix) with ESMTP id 276341863 for ; Thu, 7 Apr 2005 03:40:04 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j377e3P21307 for ; Thu, 7 Apr 2005 10:40:03 +0300 (EET DST) X-Scanned: Thu, 7 Apr 2005 10:32:36 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j377WaxY030917 for ; Thu, 7 Apr 2005 10:32:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00QLF2TL; Thu, 07 Apr 2005 10:32:34 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j377WYU24538 for ; Thu, 7 Apr 2005 10:32:34 +0300 (EET DST) Received: from [127.0.0.1] ([10.162.17.135]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 10:32:32 +0300 Message-ID: <4254E210.7020000@nokia.com> Date: Thu, 07 Apr 2005 10:32:32 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Loughney John (Nokia-NRC/Helsinki)" Cc: AAA mailing list Subject: Re: [AAA-WG]: Diameter SIP app: next steps References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2005 07:32:32.0922 (UTC) FILETIME=[F63197A0:01C53B43] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John: I agree with your statement. It seems to be a bit hard to understand that because a different protocol with different requirements came at a later stage, now we need to provide a full backwards compatibility with such protocol. I have also the same concerns regarding the timescales. We have been drafting the Diameter SIP app for a few years, and never, never, ever got requirements to support nonces generated in the client, otherwise, we would have implementted in the draft. At some point in time we have to decide to close the requirements and finish this work. I may also remind that, when progressing RFCs in the three stages of standards track, those things that are not implemented are moved out of the draft. So I have the suspicion that this nonces generated in the client will never be implemented, because we never got a requirement about this. Therefore, I think it is a waste of time to document it. I also agree that what we could do, at this stage, is to make sure that this mode of operation can be added at later stage, if someone requires it. This exersice would not take that much time now. But adding this mode of operation will delay this work for 6-9 months. So would people have a problem if we inspect the Diameter SIP app to allow easy extensibility of client-generated nonces, but we don't add this mode of operation at this time? Is this a reasonable proposal? /Miguel Loughney John (Nokia-NRC/Helsinki) wrote: > Miguel, > > >>As you probably know, the Diameter SIP application supports this >>operational mode where nonces are generated in the Diameter server. it >>could be possible to have another mode of operation where nonces are >>generated in the Diameter client (SIP server). Actually, this is the >>approach that has been taken by the RADIUS HTTP/SIP Digest draft: there >>are two modes of operation, one where nonces are generated in the RADIUS >>server; the other where nonces are generated in the RADIUS client. >> >>Since Diameter SIP app does not provide one of this modes, it won't be >>possible to provide a smooth transition or compatibility between RADIUS >>and Diameter. We have been asked to enhance the Diameter SIP application >>by adding the mode of operation where nonces are generated in the >>Diameter client (SIP server). >> >>I have been doing an investigation and there is no technical concern why >>this wouldn't work. The current Diameter SIP app draft does not >>implement this mode because we never had requirements. But now we have >>them, and we should do it. >> >>So I would be creating a new revision of the draft in the next weeks. If >>someone has any comment, please do it now. > > > What is the real requirement for this? It seems that the RADIUS HTTP/SIP > digest draft has an additional mode of operation that is not included > the Diameter SIP app. What is the usage / deployment scenario where this > is needed? If there isn't a pressing need for this, I think we should not > support this mode in the current Diameter SIP application, but leave it > to an extension if there is need or desire. > > At some point, we've got to finish this work, and not endlessly tweak this > stuff forever. Unless there is concensus on adding this feature, I don't think > we address it. > > John -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Apr 7 11:31:02 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05315 for ; Thu, 7 Apr 2005 11:31:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9D4791212; Thu, 7 Apr 2005 11:30:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 757AF912FB; Thu, 7 Apr 2005 11:30:52 -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 3ABC391212 for ; Thu, 7 Apr 2005 11:30:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 269455828E; Thu, 7 Apr 2005 11:30:51 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 0FDA55828D for ; Thu, 7 Apr 2005 11:30:51 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 149881862; Thu, 7 Apr 2005 11:30:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by testbed9.merit.edu (Postfix) with ESMTP id EA42A185B for ; Thu, 7 Apr 2005 11:30:50 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA21040 for ; Thu, 7 Apr 2005 11:31:39 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma021033; Thu, 7 Apr 05 11:31:19 -0400 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 07 Apr 2005 11:30:28 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 07 Apr 2005 11:30:27 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Apr 2005 11:30:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: digest issue 11 closure (fwd) Date: Thu, 7 Apr 2005 11:30:25 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322AB@MAANDMBX2.ets.enterasys.com> Thread-Topic: [AAA-WG]: digest issue 11 closure (fwd) Thread-Index: AcU3BJKq6nocdqyqQMK95X1mgwWhMAEONqMwABInHcA= From: "Nelson, David" To: X-OriginalArrivalTime: 07 Apr 2005 15:30:26.0975 (UTC) FILETIME=[B942DAF0:01C53B86] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0659 P:95.9108 R:95.9108 S:63.6552 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable John Loughney writes... > What you are suggesting is > that we should dumb-down Diameter SIP so that it can live > with RADIUS. However, I don't think we have a requirement for > this. Well, the RADEXT WG *does* have a requirement that RADIUS extensions be interoperable with Diameter. I guess what you're saying is that the AAA WG does *not* have a requirement that Diameter be interoperable with RADIUS extensions. There are two SIP Digest Authentication protocols, one in Diameter and one in RADIUS. My understanding is that one originated in 3GPP and the other originated in 3GPP2. Are you suggesting that these are disjoint solution sets that need not interoperate? From owner-aaa-wg@merit.edu Thu Apr 7 12:07:53 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08902 for ; Thu, 7 Apr 2005 12:07:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4712591305; Thu, 7 Apr 2005 12:07:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0473791329; Thu, 7 Apr 2005 12:07: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 892D191305 for ; Thu, 7 Apr 2005 12:07:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 73D0E5828E; Thu, 7 Apr 2005 12:07:32 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 5CE2F5828C for ; Thu, 7 Apr 2005 12:07:32 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 623A01862; Thu, 7 Apr 2005 12:07:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by testbed9.merit.edu (Postfix) with ESMTP id 38769185B for ; Thu, 7 Apr 2005 12:07:32 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 12:07:31 -0400 Message-ID: From: Avi Lior To: "'Nelson, David'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: digest issue 11 closure (fwd) Date: Thu, 7 Apr 2005 12:07:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi David, > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Thursday, April 07, 2005 11:30 AM > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: digest issue 11 closure (fwd) > > > John Loughney writes... > > > What you are suggesting is > > that we should dumb-down Diameter SIP so that it can live > with RADIUS. > > However, I don't think we have a requirement for this. > > Well, the RADEXT WG *does* have a requirement that RADIUS > extensions be interoperable with Diameter. I guess what > you're saying is that the AAA WG does *not* have a > requirement that Diameter be interoperable with RADIUS extensions. > > There are two SIP Digest Authentication protocols, one in > Diameter and one in RADIUS. My understanding is that one > originated in 3GPP and the other originated in 3GPP2. Are > you suggesting that these are disjoint solution sets that > need not interoperate? Not exactly accurate. Diameter SIP was originally based on the 3GPP requirements (Cx interface) but my understanding is that they divereged. 3GPP2 currently is using the Digest authentication for HTTP Digest authentication and not for SIP at all. So 3GPP2 is using not concerned about the SIP part and just the HTTP Digest authentication part which is what the sterman document was originally about. Note that Diameter SIP application does a lot more then RADIUS Digest authentication. So they don't interoperate. RADIUS Digest authentication is just that, Digest authentication and not a SIP application. I raised this concern before. If you want compelete SIP interoperability between RADIUS and Diameter then you need to handle those other messages that Diameter SIP has introduced. In essence you need RADIUS SIP application. So the answer to your last question: "...are these disjoint solutions sets that need not interoperate?" They answer is yes. The intent was to just get the auth part to interoperate that would be nice but if its not achievable so be it. I have my doubts about Diameter SIP. Why did 3GPP not adopt it? Is the model that Diameter SIP supports originates from 3GPP, but does it have general applicablity? Can I take the Diameter SIP and use it for other SIP architectures? From owner-aaa-wg@merit.edu Thu Apr 7 12:23:25 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10606 for ; Thu, 7 Apr 2005 12:23:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 813F5912FC; Thu, 7 Apr 2005 12:23:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5471E912FD; Thu, 7 Apr 2005 12:23:20 -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 2A87B912FC for ; Thu, 7 Apr 2005 12:23:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1421258291; Thu, 7 Apr 2005 12:23:19 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id EFCC558284 for ; Thu, 7 Apr 2005 12:23:18 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 0151F1870; Thu, 7 Apr 2005 12:23:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by testbed9.merit.edu (Postfix) with ESMTP id 742761862 for ; Thu, 7 Apr 2005 12:23:18 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j37GN6u03230; Thu, 7 Apr 2005 19:23:07 +0300 (EET DST) X-Scanned: Thu, 7 Apr 2005 19:17:22 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j37GHM6j021653; Thu, 7 Apr 2005 19:17:22 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00c8PJrH; Thu, 07 Apr 2005 19:17:21 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j37GHLU15002; Thu, 7 Apr 2005 19:17:21 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 19:17:19 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 19:17:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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]: digest issue 11 closure (fwd) Date: Thu, 7 Apr 2005 19:17:19 +0300 Message-ID: Thread-Topic: [AAA-WG]: digest issue 11 closure (fwd) thread-index: AcU7jHZ9o/DwieOKSGixMFK0fhcbvgAAHJVg From: To: , , X-OriginalArrivalTime: 07 Apr 2005 16:17:18.0355 (UTC) FILETIME=[44F96630:01C53B8D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Avi, > I have my doubts about Diameter SIP. Why did 3GPP not adopt it? Is = the > model that Diameter SIP supports originates from 3GPP, but does it = have > general applicablity? =20 Because 3GPP needed a solution for Release 5. The Diameter SIP = application would have needed to have been ready in 2002. I guess 3GPP showed good = sense not to wait on the IETF for a solution. > Can I take the Diameter SIP and use it for other SIP architectures?=20 I think Miguel has tried to make it more generally applicable for other = SIP architectures, and I have talked to some people (outside of 3GPP) who've = implemented it, so I think it is possible to use Diameter SIP outside of 3GPP. John From owner-aaa-wg@merit.edu Thu Apr 7 14:20:17 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23069 for ; Thu, 7 Apr 2005 14:20:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 63E029131F; Thu, 7 Apr 2005 14:18:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5ED891332; Thu, 7 Apr 2005 14:18:29 -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 AADC691323 for ; Thu, 7 Apr 2005 14:16:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 85D2058291; Thu, 7 Apr 2005 14:16:24 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 6C6925828E for ; Thu, 7 Apr 2005 14:16:24 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 71C4F1862; Thu, 7 Apr 2005 14:16:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by testbed9.merit.edu (Postfix) with ESMTP id 061FE185B for ; Thu, 7 Apr 2005 14:16:23 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CDFB189863; Thu, 7 Apr 2005 21:16:22 +0300 (EEST) Message-ID: <425578F6.5030802@kolumbus.fi> Date: Thu, 07 Apr 2005 21:16:22 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Cc: "'Nelson, David'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi Lior wrote: >So the answer to your last question: "...are these disjoint solutions sets >that need not interoperate?" They answer is yes. > Yes... but its not really a yes/no question. It is true that the function set in Diameter SIP is significantly bigger. But both can do Digest (and exactly at the same manner, if we can harmonize the nonce handling in Diameter SIP). You could hope for interoperability in this part*. And the translation gateway issue isn't black and white issue either. We are debating whether it should take X amount of effort to do the gateway, or X - epsilon. And to answer John's question on whether there's a current requirement for interoperability... probably not in terms of a specific customer case. But as Dave noted there's an IETF requirement on making these techniques compatible. And experience has shown that where people think their systems are entirely self sufficient, in the next customer case/specification release/business reorg they find out that they do, in fact, need to interoperate with something else. --Jari *) I'll buy you a beer if within a year, we are not discussing the RADIUS version of what exists in Diameter SIP beyond RADIUS Digest. From owner-aaa-wg@merit.edu Thu Apr 7 14:25:55 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23461 for ; Thu, 7 Apr 2005 14:25:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E23991307; Thu, 7 Apr 2005 14:25:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E435E91308; Thu, 7 Apr 2005 14:25:46 -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 560E691307 for ; Thu, 7 Apr 2005 14:25:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9C31058299; Thu, 7 Apr 2005 14:25:42 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 5734558284 for ; Thu, 7 Apr 2005 14:25:41 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id B28EE1890; Thu, 7 Apr 2005 14:25:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by testbed9.merit.edu (Postfix) with ESMTP id AD60E1895 for ; Thu, 7 Apr 2005 14:25:37 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 14:25:37 -0400 Message-ID: From: Avi Lior To: "'Jari Arkko'" , Avi Lior Cc: "'Nelson, David'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: digest issue 11 closure (fwd) Date: Thu, 7 Apr 2005 14:25:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Jari, It's a pretty safe bet that you will *not* have to buy me a beer. That is why I said we need RADIUS SIP document. Lets get the harmonizing there. And I agree since we came this far lets harmonize the authentication part. But we need 3GPP2 Digest Auth quickly now. We are delaying publication. And by Digest Auth I mean just Digest Auth nothing to do with SIP. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Thursday, April 07, 2005 2:16 PM > To: Avi Lior > Cc: 'Nelson, David'; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) > > > Avi Lior wrote: > > >So the answer to your last question: "...are these disjoint > solutions > >sets that need not interoperate?" They answer is yes. > > > Yes... but its not really a yes/no question. It is true that > the function set in Diameter SIP is significantly bigger. But > both can do Digest (and exactly at the same manner, if we can > harmonize the nonce handling in Diameter SIP). You could hope > for interoperability in this part*. > > And the translation gateway issue isn't black and white > issue either. We are debating whether it should take > X amount of effort to do the gateway, or X - epsilon. > > And to answer John's question on whether there's a current > requirement for interoperability... probably not in terms of > a specific customer case. But as Dave noted there's an IETF > requirement on making these techniques compatible. And > experience has shown that where people think their systems > are entirely self sufficient, in the next customer > case/specification release/business reorg they find out that > they do, in fact, need to interoperate with something else. > > --Jari > > *) I'll buy you a beer if within a year, we are not > discussing the RADIUS version of what exists in Diameter SIP > beyond RADIUS Digest. > From owner-aaa-wg@merit.edu Thu Apr 7 14:34:45 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24403 for ; Thu, 7 Apr 2005 14:34:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 66DA891314; Thu, 7 Apr 2005 14:33:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29B1D9131C; Thu, 7 Apr 2005 14: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 C758991314 for ; Thu, 7 Apr 2005 14:33:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B63A75828C; Thu, 7 Apr 2005 14:33:36 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 9CDAE58284 for ; Thu, 7 Apr 2005 14:33:36 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id A29521862; Thu, 7 Apr 2005 14:33:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by testbed9.merit.edu (Postfix) with ESMTP id 542B4185B for ; Thu, 7 Apr 2005 14:33:36 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 63DD489863; Thu, 7 Apr 2005 21:33:35 +0300 (EEST) Message-ID: <42557CFF.6000602@kolumbus.fi> Date: Thu, 07 Apr 2005 21:33:35 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Cc: "'Nelson, David'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi Lior wrote: >Jari, > >It's a pretty safe bet that you will *not* have to buy me a beer. That is >why I said we need RADIUS SIP document. Lets get the harmonizing there. > > Ok. Either you are right or you get beer. Sounds good, no? >And I agree since we came this far lets harmonize the authentication part. >But we need 3GPP2 Digest Auth quickly now. We are delaying publication. >And by Digest Auth I mean just Digest Auth nothing to do with SIP. > > It looks like the issues that we are discussing right now are in the Diameter SIP part, like adding the nonce thing or keeping/removing the grouped AVP. In that sense its not delaying RADIUS SIP, although obviously it would be good to ensure that the two can be in sync before we commit one of them to an RFC... --Jari > > > > >>-----Original Message----- >>From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] >>Sent: Thursday, April 07, 2005 2:16 PM >>To: Avi Lior >>Cc: 'Nelson, David'; aaa-wg@merit.edu >>Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) >> >> >>Avi Lior wrote: >> >> >> >>>So the answer to your last question: "...are these disjoint >>> >>> >>solutions >> >> >>>sets that need not interoperate?" They answer is yes. >>> >>> >>> >>Yes... but its not really a yes/no question. It is true that >>the function set in Diameter SIP is significantly bigger. But >>both can do Digest (and exactly at the same manner, if we can >>harmonize the nonce handling in Diameter SIP). You could hope >>for interoperability in this part*. >> >>And the translation gateway issue isn't black and white >>issue either. We are debating whether it should take >>X amount of effort to do the gateway, or X - epsilon. >> >>And to answer John's question on whether there's a current >>requirement for interoperability... probably not in terms of >>a specific customer case. But as Dave noted there's an IETF >>requirement on making these techniques compatible. And >>experience has shown that where people think their systems >>are entirely self sufficient, in the next customer >>case/specification release/business reorg they find out that >>they do, in fact, need to interoperate with something else. >> >>--Jari >> >>*) I'll buy you a beer if within a year, we are not >>discussing the RADIUS version of what exists in Diameter SIP >>beyond RADIUS Digest. >> >> >> > > > From owner-aaa-wg@merit.edu Thu Apr 7 14:36:38 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24561 for ; Thu, 7 Apr 2005 14:36:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 51A6191308; Thu, 7 Apr 2005 14:36:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 064C191309; Thu, 7 Apr 2005 14:36:28 -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 E4DA091308 for ; Thu, 7 Apr 2005 14:36:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D30205828E; Thu, 7 Apr 2005 14:36:27 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id B83065828C for ; Thu, 7 Apr 2005 14:36:27 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id BC2011877; Thu, 7 Apr 2005 14:36:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by testbed9.merit.edu (Postfix) with ESMTP id 903DF1870 for ; Thu, 7 Apr 2005 14:36:27 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 82CEB8983A; Thu, 7 Apr 2005 21:03:21 +0300 (EEST) Message-ID: <425575E9.60604@kolumbus.fi> Date: Thu, 07 Apr 2005 21:03:21 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Cc: "'Nelson, David'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi Lior wrote: >I have my doubts about Diameter SIP. Why did 3GPP not adopt it? Is the >model that Diameter SIP supports originates from 3GPP, but does it have >general applicablity? Can I take the Diameter SIP and use it for other SIP >architectures? > > 3GPP is using something which can be considered to be the pre-release version of Diameter SIP; they needed the protocol before work on Diameter SIP could be done, particularly when the AAA WG was at the time still strugling with the base protocol definitions. I believe there is some intent on updating once IETF versions are available, but it remains to be seen when (and if) this really happens. --Jari From owner-aaa-wg@merit.edu Thu Apr 7 14:37:14 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24692 for ; Thu, 7 Apr 2005 14:37:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F52591309; Thu, 7 Apr 2005 14:37:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 584579130A; Thu, 7 Apr 2005 14:37: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 2040391309 for ; Thu, 7 Apr 2005 14:37:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0ABE75828E; Thu, 7 Apr 2005 14:37:09 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id E5C985828C for ; Thu, 7 Apr 2005 14:37:08 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id EC13F1877; Thu, 7 Apr 2005 14:37:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by testbed9.merit.edu (Postfix) with ESMTP id C94D41870 for ; Thu, 7 Apr 2005 14:37:08 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 14:37:08 -0400 Message-ID: From: Avi Lior To: "'Jari Arkko'" , Avi Lior Cc: "'Nelson, David'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: digest issue 11 closure (fwd) Date: Thu, 7 Apr 2005 14:37:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Thursday, April 07, 2005 2:34 PM > To: Avi Lior > Cc: 'Nelson, David'; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) > > > Avi Lior wrote: > > >Jari, > > > >It's a pretty safe bet that you will *not* have to buy me a > beer. That > >is why I said we need RADIUS SIP document. Lets get the > harmonizing there. > > > > > Ok. Either you are right or you get beer. Sounds good, no? Hmmmmm, Yes!!!! You don't get many of those... > >And I agree since we came this far lets harmonize the authentication > >part. But we need 3GPP2 Digest Auth quickly now. We are delaying > >publication. And by Digest Auth I mean just Digest Auth > nothing to do > >with SIP. > > > > > It looks like the issues that we are discussing right now are > in the Diameter SIP part, like adding the nonce thing or > keeping/removing the grouped AVP. In that sense its not > delaying RADIUS SIP, although obviously it would be good to > ensure that the two can be in sync before we commit one of > them to an RFC... Great...as long as we can wrapup RADIUS Digest. > --Jari > > > > > > > > > > >>-----Original Message----- > >>From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > >>Sent: Thursday, April 07, 2005 2:16 PM > >>To: Avi Lior > >>Cc: 'Nelson, David'; aaa-wg@merit.edu > >>Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) > >> > >> > >>Avi Lior wrote: > >> > >> > >> > >>>So the answer to your last question: "...are these disjoint > >>> > >>> > >>solutions > >> > >> > >>>sets that need not interoperate?" They answer is yes. > >>> > >>> > >>> > >>Yes... but its not really a yes/no question. It is true that > >>the function set in Diameter SIP is significantly bigger. But > >>both can do Digest (and exactly at the same manner, if we can > >>harmonize the nonce handling in Diameter SIP). You could hope > >>for interoperability in this part*. > >> > >>And the translation gateway issue isn't black and white > >>issue either. We are debating whether it should take > >>X amount of effort to do the gateway, or X - epsilon. > >> > >>And to answer John's question on whether there's a current > >>requirement for interoperability... probably not in terms of > >>a specific customer case. But as Dave noted there's an IETF > >>requirement on making these techniques compatible. And > >>experience has shown that where people think their systems > >>are entirely self sufficient, in the next customer > >>case/specification release/business reorg they find out that > >>they do, in fact, need to interoperate with something else. > >> > >>--Jari > >> > >>*) I'll buy you a beer if within a year, we are not > >>discussing the RADIUS version of what exists in Diameter SIP > >>beyond RADIUS Digest. > >> > >> > >> > > > > > > > From owner-aaa-wg@merit.edu Thu Apr 7 14:52:12 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26321 for ; Thu, 7 Apr 2005 14:52:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4EE9A9130A; Thu, 7 Apr 2005 14:52:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FC1F9130C; Thu, 7 Apr 2005 14:52: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 066369130A for ; Thu, 7 Apr 2005 14:52:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E82BA5828C; Thu, 7 Apr 2005 14:52:04 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id D0D1E58284 for ; Thu, 7 Apr 2005 14:52:04 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id D6EF31862; Thu, 7 Apr 2005 14:52:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by testbed9.merit.edu (Postfix) with ESMTP id BE992185B for ; Thu, 7 Apr 2005 14:52:02 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DJc6j-0007Af-MA; Thu, 07 Apr 2005 14:52:01 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j37Iq0B23231; Thu, 7 Apr 2005 11:52:00 -0700 Date: Thu, 7 Apr 2005 11:51:59 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: digest issue 11 closure (fwd) In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322AB@MAANDMBX2.ets.enterasys.com> Message-ID: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322AB@MAANDMBX2.ets.enterasys.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk > Well, the RADEXT WG *does* have a requirement that RADIUS extensions be > interoperable with Diameter. I guess what you're saying is that the AAA > WG does *not* have a requirement that Diameter be interoperable with > RADIUS extensions. The original idea was for Diameter to offer a superset of RADIUS functionality, so that it would be possible to install Diameter agents and servers in a network with RADIUS-capable NAS devices. This was thought to be important because common NAS devices do not today support Diameter, and may not do so for a long time. At the same time, Diameter needed to be able to offer functionality such as improved transport and new applications that could not be built on top of RADIUS. Since RADIUS could not provide some of those features, interoperability was not required for those elements (such as failover, and Credit Control). > There are two SIP Digest Authentication protocols, one in Diameter and > one in RADIUS. My understanding is that one originated in 3GPP and the > other originated in 3GPP2. Are you suggesting that these are disjoint > solution sets that need not interoperate? As far as I can see SIP Digest authentication does not require use of features uniquely available in Diameter. Since this is a new application, one might posit that deployments will largely focus on Diameter rather than RADIUS, but that is a hypothesis which could be wrong. If in fact RADIUS Digest becomes popular, then it may become necessary to gateway RADIUS Digest to Diameter SIP, and without interoperability that could be hard. Why tempt fate? From owner-aaa-wg@merit.edu Thu Apr 7 15:51:23 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02015 for ; Thu, 7 Apr 2005 15:51:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2362E9130D; Thu, 7 Apr 2005 15:51:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E06DB9130E; Thu, 7 Apr 2005 15:51:16 -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 A46C89130D for ; Thu, 7 Apr 2005 15:51:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D98E58297; Thu, 7 Apr 2005 15:51:15 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 73C175828C for ; Thu, 7 Apr 2005 15:51:15 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 789141862; Thu, 7 Apr 2005 15:51:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ws6-1.us4.outblaze.com (ws6-1.us4.outblaze.com [205.158.62.196]) by testbed9.merit.edu (Postfix) with ESMTP id 50E65185B for ; Thu, 7 Apr 2005 15:51:13 -0400 (EDT) Received: by ws6-1.us4.outblaze.com (Postfix, from userid 1001) id 97510EDE5A; Thu, 7 Apr 2005 19:51:07 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [127.0.0.1] by ws6-1.us4.outblaze.com with http for david@mitton.com; Thu, 07 Apr 2005 14:51:07 -0500 From: "David Mitton" To: john.loughney@nokia.com, aboba@internaut.com, aaa-wg@merit.edu Date: Thu, 07 Apr 2005 14:51:07 -0500 Subject: RE: [AAA-WG]: RE: draft-mitton-diameter-radius-vsas-00.txt X-Originating-Ip: 127.0.0.1 X-Originating-Server: ws6-1.us4.outblaze.com Message-Id: <20050407195107.97510EDE5A@ws6-1.us4.outblaze.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Ummm... I'm not sure who all is involved in this discussion. I initially disclosed a draft copy to the AAA chairs for comment before=20 submission, but there seems to be some included text and trailers that don'= t correspond to the=20 headers, or my intended recipients. The draft has not been posted to the Secretariat at this writing, but I gue= ss=20 I might do it as-is now, so that everyone can join in. FYI: RFC 4005 is Diameter Nasreq, currently in Auth48 state. Dave. ----- Original Message ----- From: john.loughney@nokia.com To: aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: draft-mitton-diameter-radius-vsas-00.txt Date: Thu, 7 Apr 2005 09:43:38 +0300 > > Bernard, > > Bumping it up a level, still. I do not think that there is a perfect > solution for interworking RADIUS and Diameter. Interworking will always > be interworking. Toss in VSAs and all bets are off. > > I think we should have some basic, default case (which I think the draft > is trying to address). This may cover some cases, but not all, but I > don't see how we can guarentee 100% interworking. I think there will > be some need for some interworking boxes that may need to normalize > or translate between RADIUS and Diameter, but that kind of thing probably > is more implementational than standards-based. > > Some time ago, there was discussion about working on a BCP or information > draft on Diameter-RADIUS interworking; perhaps that is something that > is still needed. However, its not reasonable to hold NASREQ (or any other > Diameter document) up based on this issue. > > John > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > ext Bernard Aboba > > Sent: 07 April, 2005 08:03 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: RE: draft-mitton-diameter-radius-vsas-00.txt > > > > > > Maybe we should talk a bit about the problem this draft was trying to > > solve. > > > > As I understand it, we have a number of potential translation issues in > > NASREQ and Diameter EAP: > > > > 1. Translation of specific RADIUS VSAs to Diameter standard attributes. > > This is an issue in Diameter EAP for translation of RFC 2548 keying > > attributes to Diameter keying attributes. > > > > 2. Translation of RADIUS VSAs in the illustrated RFC 2865 VSA format to > > Diameter VSAs and back. > > > > 3. Translation of RADIUS VSAs *not* conforming to the proposed RFC 2865 > > VSA format to Diameter VSAs and back. > > > > Note that I'm not including the problem of translating from an arbitrary > > Diameter VSA to a RADIUS VSA because as you point out, this is not > > possible. > > > > The question is how one can handle these cases together within a > > Diameter/RADIUS gateway. > > > > One way to think about it is a hierarchy of potential translations: > > > > a. Specific translations. If you find a particular RADIUS VSA that's on > > the specific list, the gateway executes the translation for that > > particular VSA. > > > > b. Generic RFC 2865 VSA format translations. If the SMI for a particul= ar > > VSA is on the "Generic" list then it is translated to a Diameter VSA as > > specified in the original NASREQ document. > > > > c. Default case. If the SMI for a particular VSA is *not* on the > > "Generic" list, what do you do? This is what I thought your proposal w= as > > addressing. > > > > > > > > > ---------- Forwarded message ---------- > > > Date: Tue, 05 Apr 2005 22:55:17 -0400 > > > From: David Mitton > > > To: Bernard Aboba , > > > John Loughney > > > Subject: draft-mitton-diameter-radius-vsas-00.txt > > > > > > Bernard, John, > > > > > > Take a quick look at this and I can submit it. > > > > > > Next I'll do a change edit for draft RFC 4005, Section 9 that > > > references this. > > > > This draft looks amazingly similar to a solution I proposed, but now > > repudiate. I had thought that the simplest way to deal with the > > attribute translation would be not to do it: to (essentially) tunnel > > the RADIUS attributes through Diameter & vice-versa, which is > > basically what this draft seems to do. Since, however, I've come to > > the conclusion that RADIUS-Diameter NASREQ interworking is, in the > > general case, impossible without seriously restricting Diameter > > semantics, making major changes to RADIUS or both. The problem is > > simply one of arithmetic, something this draft has a little problem > > with as well: section 3.2 says "Diameter AVPs data field can be 16K > > bytes long (length 24 bits)", but the last time I checked the > > maximum 24-bit value was around 16 _megabytes_, not 16 _kilobytes_, > > but that's really immaterial. Even if the maximum length of a > > Diameter AVP was roughly 16K, that's still more than 4 times the > > maximum size of a RADIUS _message_. It just won't fit. Note that > > this problem is there even with the "standard" NASREQ AVPs (the ones > > numbered to coincide with the RADIUS standard attributes). Suppose, > > for example, that I want to use a 6 KB string representation of a PK > > cert as my user name. A Diameter client might have no problem with > > this, but it certainly would fail at the first RADIUS-Diameter > > gateway. Similarly, a Diameter server has no way to know (AFAIK, > > please correct me if I'm wrong) that the client at the other end is > > actually a RADIUS client. Therefore, it would be perfectly > > reasonable for it to return an 8 KB AVP, which would never get to > > its proper destination. The only way I can imagine this working is > > if there was a "RADIUS compatibility mode" for Diameter in which the > > RADIUS rules were followed (including maximum message length). > > > > > > > > Dave. > > > > Hope this helps, > > > > ~gwz > > > > Why is it that most of the world's problems can't be solved by > > simply > > listening to John Coltrane? -- Henry Gabriel > > From owner-aaa-wg@merit.edu Thu Apr 7 17:22:58 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09864 for ; Thu, 7 Apr 2005 17:22:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C653191265; Thu, 7 Apr 2005 17:22:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FBC291268; Thu, 7 Apr 2005 17:22:52 -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 2286491265 for ; Thu, 7 Apr 2005 17:22:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 076745828E; Thu, 7 Apr 2005 17:22:51 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id DBCCB5828C for ; Thu, 7 Apr 2005 17:22:50 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id DEB0B187B; Thu, 7 Apr 2005 17:22:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by testbed9.merit.edu (Postfix) with ESMTP id A740B180C for ; Thu, 7 Apr 2005 17:22:50 -0400 (EDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 07 Apr 2005 14:22:50 -0700 Received: from gwzw2k01 (sjc-vpn7-150.cisco.com [10.21.144.150]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j37LMk3S007972; Thu, 7 Apr 2005 14:22:47 -0700 (PDT) Message-Id: <200504072122.j37LMk3S007972@sj-core-4.cisco.com> Reply-To: From: "Glen Zorn (gwz)" To: "'David Mitton'" , , , Subject: RE: [AAA-WG]: RE: draft-mitton-diameter-radius-vsas-00.txt Date: Thu, 7 Apr 2005 14:22:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcU7q3NQ4L6k6huMS2+2XaVByZMiPAADCOeg X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <20050407195107.97510EDE5A@ws6-1.us4.outblaze.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Mitton <> supposedly scribbled: > Ummm... I'm not sure who all is involved in this discussion. I was rather surprised (to put it mildly) to find my private reply forwarded to half the world, as well. > > I initially disclosed a draft copy to the AAA chairs for comment > before submission, but there seems to be some included text and > trailers that don't correspond to the headers, or my intended > recipients. > > The draft has not been posted to the Secretariat at this writing, but > I guess I might do it as-is now, so that everyone can join in. I suppose so. > > FYI: RFC 4005 is Diameter Nasreq, currently in Auth48 state. > > Dave. > > ----- Original Message ----- > From: john.loughney@nokia.com > To: aboba@internaut.com, aaa-wg@merit.edu > Subject: RE: [AAA-WG]: RE: draft-mitton-diameter-radius-vsas-00.txt > Date: Thu, 7 Apr 2005 09:43:38 +0300 > >> >> Bernard, >> >> Bumping it up a level, still. I do not think that there is a perfect >> solution for interworking RADIUS and Diameter. Interworking will >> always be interworking. Toss in VSAs and all bets are off. >> >> I think we should have some basic, default case (which I think the >> draft is trying to address). This may cover some cases, but not all, >> but I don't see how we can guarentee 100% interworking. I think >> there will be some need for some interworking boxes that may need to >> normalize or translate between RADIUS and Diameter, but that kind of >> thing probably is more implementational than standards-based. >> >> Some time ago, there was discussion about working on a BCP or >> information draft on Diameter-RADIUS interworking; perhaps that is >> something that is still needed. However, its not reasonable to hold >> NASREQ (or any other Diameter document) up based on this issue. >> >> John >> >>> -----Original Message----- >>> From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On >>> Behalf Of ext Bernard Aboba >>> Sent: 07 April, 2005 08:03 >>> To: aaa-wg@merit.edu >>> Subject: [AAA-WG]: RE: draft-mitton-diameter-radius-vsas-00.txt >>> >>> >>> Maybe we should talk a bit about the problem this draft was trying >>> to solve. >>> >>> As I understand it, we have a number of potential translation >>> issues in NASREQ and Diameter EAP: >>> >>> 1. Translation of specific RADIUS VSAs to Diameter standard >>> attributes. This is an issue in Diameter EAP for translation of RFC >>> 2548 keying attributes to Diameter keying attributes. >>> >>> 2. Translation of RADIUS VSAs in the illustrated RFC 2865 VSA >>> format to Diameter VSAs and back. >>> >>> 3. Translation of RADIUS VSAs *not* conforming to the proposed RFC >>> 2865 VSA format to Diameter VSAs and back. >>> >>> Note that I'm not including the problem of translating from an >>> arbitrary Diameter VSA to a RADIUS VSA because as you point out, >>> this is not possible. >>> >>> The question is how one can handle these cases together within a >>> Diameter/RADIUS gateway. >>> >>> One way to think about it is a hierarchy of potential translations: >>> >>> a. Specific translations. If you find a particular RADIUS VSA >>> that's on the specific list, the gateway executes the translation >>> for that particular VSA. >>> >>> b. Generic RFC 2865 VSA format translations. If the SMI for a >>> particular VSA is on the "Generic" list then it is translated to a >>> Diameter VSA as specified in the original NASREQ document. >>> >>> c. Default case. If the SMI for a particular VSA is *not* on the >>> "Generic" list, what do you do? This is what I thought your >>> proposal was addressing. >>> >>> >>> >>>> ---------- Forwarded message ---------- >>>> Date: Tue, 05 Apr 2005 22:55:17 -0400 >>>> From: David Mitton >>>> To: Bernard Aboba , >>>> John Loughney >>>> Subject: draft-mitton-diameter-radius-vsas-00.txt >>>> >>>> Bernard, John, >>>> >>>> Take a quick look at this and I can submit it. >>>> >>>> Next I'll do a change edit for draft RFC 4005, Section 9 that >>>> references this. >>> >>> This draft looks amazingly similar to a solution I proposed, but now >>> repudiate. I had thought that the simplest way to deal with the >>> attribute translation would be not to do it: to (essentially) tunnel >>> the RADIUS attributes through Diameter & vice-versa, which is >>> basically what this draft seems to do. Since, however, I've come to >>> the conclusion that RADIUS-Diameter NASREQ interworking is, in the >>> general case, impossible without seriously restricting Diameter >>> semantics, making major changes to RADIUS or both. The problem is >>> simply one of arithmetic, something this draft has a little problem >>> with as well: section 3.2 says "Diameter AVPs data field can be 16K >>> bytes long (length 24 bits)", but the last time I checked the >>> maximum 24-bit value was around 16 _megabytes_, not 16 _kilobytes_, >>> but that's really immaterial. Even if the maximum length of a >>> Diameter AVP was roughly 16K, that's still more than 4 times the >>> maximum size of a RADIUS _message_. It just won't fit. Note that >>> this problem is there even with the "standard" NASREQ AVPs (the ones >>> numbered to coincide with the RADIUS standard attributes). Suppose, >>> for example, that I want to use a 6 KB string representation of a PK >>> cert as my user name. A Diameter client might have no problem with >>> this, but it certainly would fail at the first RADIUS-Diameter >>> gateway. Similarly, a Diameter server has no way to know (AFAIK, >>> please correct me if I'm wrong) that the client at the other end is >>> actually a RADIUS client. Therefore, it would be perfectly >>> reasonable for it to return an 8 KB AVP, which would never get to >>> its proper destination. The only way I can imagine this working is >>> if there was a "RADIUS compatibility mode" for Diameter in which the >>> RADIUS rules were followed (including maximum message length). >>> >>>> >>>> Dave. >>> >>> Hope this helps, >>> >>> ~gwz >>> >>> Why is it that most of the world's problems can't be solved by >>> simply >>> listening to John Coltrane? -- Henry Gabriel Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel From owner-aaa-wg@merit.edu Fri Apr 8 02:51:16 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10734 for ; Fri, 8 Apr 2005 02:51:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9F28791233; Fri, 8 Apr 2005 02:51:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64A0D91236; Fri, 8 Apr 2005 02:51:08 -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 56A7F91233 for ; Fri, 8 Apr 2005 02:51:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 406995828F; Fri, 8 Apr 2005 02:51:07 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 2911C5828C for ; Fri, 8 Apr 2005 02:51:07 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 2E36D187F; Fri, 8 Apr 2005 02:51:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by testbed9.merit.edu (Postfix) with ESMTP id B52C91877 for ; Fri, 8 Apr 2005 02:51:05 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j386oxV06861; Fri, 8 Apr 2005 09:51:00 +0300 (EET DST) X-Scanned: Fri, 8 Apr 2005 09:44:46 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j386ikdx030877; Fri, 8 Apr 2005 09:44:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00rYqYBF; Fri, 08 Apr 2005 09:44:44 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j386QjM13387; Fri, 8 Apr 2005 09:26:45 +0300 (EET DST) Received: from [127.0.0.1] ([172.21.39.90]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 8 Apr 2005 09:26:40 +0300 Message-ID: <42562420.6060604@nokia.com> Date: Fri, 08 Apr 2005 09:26:40 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Avi Lior Cc: "'Nelson, David'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: digest issue 11 closure (fwd) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2005 06:26:40.0197 (UTC) FILETIME=[EC995F50:01C53C03] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Avi Lior wrote: > > I have my doubts about Diameter SIP. Why did 3GPP not adopt it? Is the > model that Diameter SIP supports originates from 3GPP, but does it have > general applicablity? Can I take the Diameter SIP and use it for other SIP > architectures? > > Yes, that is the idea. The Diameter SIP application is largely based on the 3GPP Diameter application for the Cx interface. However, we have generalized the 3GPP stuff to make it applicable to the public Internet. As such, I have always been trying to remove a bunch of assumptions that were only valid in 3GPP (e.g., Digest AKA, first SIP request contains username, avoid assuming there is a single profile type, etc.) So if you want to put Diameter SIP app to work in 3GPP, it will work correctly. If you want to make it work in an ISP that is not related to 3GPP, it will work as well. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland From einet@doramail.com Sat Apr 9 15:53:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03655 for ; Sat, 9 Apr 2005 15:53:45 -0400 (EDT) Received: from d57-175-189.home.cgocable.net ([24.57.175.189]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKMAc-0001Zf-11 for aaa-archive@ietf.org; Sat, 09 Apr 2005 16:03:07 -0400 Authentication-Results: pyrimidine.es from=premium.baronet.es; domainkeys=neutral (no sig) X-Originating-IP: [81.12.160.103] Received: from premium.concocter.es (EHLO premium.delusive.es) by premium.sherman.es with SMTP; Sat, 09 Apr 2005 19:42:22 -0100 Date: Sun, 10 Apr 2005 02:49:22 +0600 From: "Evangelina Bourgeois" To: -announce@ietf.org Cc: -archive@ietf.org, -drafts@ietf.org, -impl-archive@ietf.org, -web-archive@ietf.org, ..@ietf.org, _@ietf.org, a@ietf.org, aaa@ietf.org, aaa-archive@ietf.org Subject: Lowest rate approval Message-ID: <115541.0094.einet@doramail.com> X-Mailer: Kana Connect 6 X-Spam-Score: 4.0 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Brendan Herron to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From dcmdc@yebox.com Sat Apr 9 16:45:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06792 for ; Sat, 9 Apr 2005 16:45:32 -0400 (EDT) Received: from [222.99.253.32] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKMyi-0003wK-JC for aaa-archive@ietf.org; Sat, 09 Apr 2005 16:54:54 -0400 Authentication-Results: oldsmobile.es from=premium.parliamentary.es; domainkeys=neutral (no sig) X-Originating-IP: [128.196.103.74] Received: from premium.feature.es (EHLO premium.cull.es) by premium.berglund.es with SMTP; Sat, 09 Apr 2005 15:42:17 -0600 Date: Sat, 09 Apr 2005 17:40:17 -0400 From: "Elise Dean" To: -announce@ietf.org Cc: -archive@ietf.org, -drafts@ietf.org, -impl-archive@ietf.org, -web-archive@ietf.org, ..@ietf.org, _@ietf.org, a@ietf.org, aaa@ietf.org, aaa-archive@ietf.org, aaa-web-archive@ietf.org Subject: Need a low mortage rate? Message-ID: <115141.6050.dcmdc@yebox.com> X-Mailer: Kana Connect 6 X-Spam-Score: 9.1 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Harrison Waters to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-aaa-wg@merit.edu Sun Apr 10 13:43:34 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05262 for ; Sun, 10 Apr 2005 13:43:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3CF3C912A6; Sun, 10 Apr 2005 13:43:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12728912A7; Sun, 10 Apr 2005 13:43:27 -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 16FF0912A6 for ; Sun, 10 Apr 2005 13:43:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F2C6F5829E; Sun, 10 Apr 2005 13:43:26 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id DCE4F5828B for ; Sun, 10 Apr 2005 13:43:26 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id E2E371886; Sun, 10 Apr 2005 13:43:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by testbed9.merit.edu (Postfix) with ESMTP id D467E181D for ; Sun, 10 Apr 2005 13:43:26 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DKgSz-0006gO-SR for aaa-wg@merit.edu; Sun, 10 Apr 2005 13:43:25 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j3AHhOv23716 for ; Sun, 10 Apr 2005 10:43:24 -0700 Date: Sun, 10 Apr 2005 10:43:24 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Any last comments on draft-adrangi-eap-network-discovery-12.txt? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk The -12 version of the EAP Network Discovery document is now available on the IETF archive at: http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-12.txt This document has requested publication as an Informational RFC via the RFC editor individual submissino route. Unless we hear any comments by Monday, April 18, 2005 we are going to assume this document has completed review and we will inform the IESG of that. So if you any remaining issues, please post them to the EAP WG mailing list (eap@frascone.com). Note: there appears to be an IPR claim related to this document: http://www.ietf.org/ietf/IPR/telecom-italia-ipr-wlan-access.txt From riddled@yebox.com Tue Apr 12 07:48:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21576; Tue, 12 Apr 2005 07:48:27 -0400 (EDT) Received: from [221.154.144.111] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLK28-0006Ad-JK; Tue, 12 Apr 2005 07:58:22 -0400 Delivered-To: dubhe@depute.dreamhost.com Received: from geriatric.dreamhost.com by paragonite.dreamhost.com (Pingofix) with ESMTP id 4CC6A87D6B for ; Tue, 12 Apr 2005 07:41:34 -0500 Message-ID: Date: Tue, 12 Apr 2005 09:37:34 -0300 From: "Tod Hunter" To: <-announce@ietf.org> Subject: Re-finance at todays low rate X-Mailer: Mailman v2.0.0 X-SpamTest-Info: Profile: Formal (167/041114) X-SpamTest-Info: Profile: Detect Hard No RBL (4/030549) X-Spam-Score: 15.3 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Frances Coates to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-aaa-wg@merit.edu Tue Apr 12 08:26:26 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24416 for ; Tue, 12 Apr 2005 08:26:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C6B491211; Tue, 12 Apr 2005 08:26:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27FF1912DF; Tue, 12 Apr 2005 08:26:09 -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 AAB5791211 for ; Tue, 12 Apr 2005 08:26:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 926C258289; Tue, 12 Apr 2005 08:26:07 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 4EEE358286 for ; Tue, 12 Apr 2005 08:26:07 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 54F271874; Tue, 12 Apr 2005 08:26:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by testbed9.merit.edu (Postfix) with ESMTP id 2DFA01861 for ; Tue, 12 Apr 2005 08:26:06 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 36so1395975wra for ; Tue, 12 Apr 2005 05:26:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=QWU+4tFcdm1Hf19haQoXiYxzi4qo2QgmmiH4XQgjGtP6Fn11VL+NFp/3jm+D+UgjHVrDHo+/zq6QMLPdRGCbFMdG/G9We+Uox5NZgG8cUzsgehCQd11502RYAQX/LZBUtstaf9fPcQ82GXQKQ4+eb9WjxQlfzFUGTknoV5MutC8= Received: by 10.54.55.6 with SMTP id d6mr2990797wra; Tue, 12 Apr 2005 05:26:06 -0700 (PDT) Received: by 10.54.43.21 with HTTP; Tue, 12 Apr 2005 05:26:05 -0700 (PDT) Message-ID: Date: Tue, 12 Apr 2005 14:26:05 +0200 From: Jo Hermans Reply-To: Jo Hermans To: aaa-wg@merit.edu Subject: [AAA-WG]: issue with expected response calculation Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1528_3917012.1113308765929" Sender: owner-aaa-wg@merit.edu Precedence: bulk ------=_Part_1528_3917012.1113308765929 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have a problem with paragraph 8.5.6.1 in=20 draft-ietf-aaa-diameter-sip-app-07 , 3th paragraph ("Please note that the= =20 expected response ...") The draft mentions that the expected response calculation can't be done whe= n=20 the SIP UA has sent a expected response based on client nonces. It then=20 mentions that this is the case when the qop-parameter is present in the=20 client request. That last part I don't understand. I though that H(A1) is dependent on the= =20 algorithm, not qop. Qop has only influence on the A2 and digest, which are= =20 both calculated in the Diameter Client (SIP Server). See also < http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue40> But even then I don't understand. I think that the Diameter Server does has= =20 the client-nonces available (they're in the SIP-Authorization AVP, and were= =20 used to calculate the request digest !)), and is able to calculate a H(A1).= =20 Even if MD5-sess was used, it could still calculate H(A1). MD5-sess also ha= s=20 the added advantage that H(A1) could only be used once, which is also the= =20 reason why draft-sterman-aaa-sip-04.txt doesn't want to use MD5 unless the= =20 message is protected against eavesdropping. I agree that if qop is missing and algorithm is MD5, client-nonces aren't= =20 used at all (backwards compatibility with RFC2069). H(A1) might be stored= =20 inside the Diameter Client (SIP server) when it's first received, and reuse= d=20 later on. Is it this that the draft is alluding to ? --=20 Jo Hermans "Eagles may soar, but weasels aren't sucked into jet engines" ------=_Part_1528_3917012.1113308765929 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have a problem with paragraph 8.5.6.1 in draft-ietf-aaa-diameter-sip-app-07 , 3th paragraph ("Please note that the expected response ...")

The draft mentions that the expected response calculation can't be done when the SIP UA has sent a expected response based on client nonces. It then mentions that this is the case when the qop-parameter is present in the client request.

That last part I don't understand. I though that H(A1) is dependent on the algorithm, not qop. Qop has only influence on the A2 and digest, which are both calculated in the Diameter Client (SIP Server).  See also <http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue40&= gt;

But even then I don't understand. I think that the Diameter Server does has the client-nonces available (they're in the SIP-Authorization AVP, and were used to calculate the request digest !)), and is able to calculate a H(A1). Even if MD5-sess was used, it could still calculate H(A1). MD5-sess also has the added advantage that H(A1) could only be used once, which is also the reason why draft-sterman-aaa-sip-04.txt doesn't want to use MD5 unless the message is protected against eavesdropping.

I agree that if qop is missing and algorithm is MD5, client-nonces aren't used at all (backwards compatibility with RFC2069). H(A1) might be stored inside the Diameter Client (SIP server) when it's first received, and reused later on. Is it this that the draft is alluding to ?

--
Jo Hermans

"Eagles may soar, but weasels aren't suck= ed into jet engines" ------=_Part_1528_3917012.1113308765929-- From owner-aaa-wg@merit.edu Tue Apr 12 18:45:44 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20591 for ; Tue, 12 Apr 2005 18:45:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C6FBD912F1; Tue, 12 Apr 2005 18:45:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CC13912F6; Tue, 12 Apr 2005 18:45: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 BC337912F1 for ; Tue, 12 Apr 2005 18:45:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F9D75828A; Tue, 12 Apr 2005 18:45:21 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 83FB058285 for ; Tue, 12 Apr 2005 18:45:21 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 8AB1C185B; Tue, 12 Apr 2005 18:45:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by testbed9.merit.edu (Postfix) with ESMTP id 3A3D41863 for ; Tue, 12 Apr 2005 18:45:20 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 67so3753202wri for ; Tue, 12 Apr 2005 15:45:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=JI1tM8FF96ReF2jT/kkZE2CY759XHSR14LuZxpJ6qLuZFlxQYRQD9JwrM4+2FT/L3xJQjuZQyBv/5h3Shc+gVz3DTA0r4b3+M84Sgb58RzVCm3xSMQNbmeI34r012HD4S0AsYs6q/yup2zjgDdvs9kTLVdBfxkCjH5NVOzJf1WE= Received: by 10.54.43.78 with SMTP id q78mr1524622wrq; Tue, 12 Apr 2005 15:44:20 -0700 (PDT) Received: by 10.54.43.21 with HTTP; Tue, 12 Apr 2005 15:44:15 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 00:44:15 +0200 From: Jo Hermans Reply-To: Jo Hermans To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue with expected response calculation In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13_16954606.1113345855892" References: Sender: owner-aaa-wg@merit.edu Precedence: bulk ------=_Part_13_16954606.1113345855892 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Replying on my own question ... On 4/12/05, Jo Hermans wrote: >=20 > I have a problem with paragraph 8.5.6.1 in=20 > draft-ietf-aaa-diameter-sip-app-07 , 3th paragraph ("Please note that the= =20 > expected response ...") >=20 > The draft mentions that the expected response calculation can't be done= =20 > when the SIP UA has sent a expected response based on client nonces. It t= hen=20 > mentions that this is the case when the qop-parameter is present in the= =20 > client request. >=20 > That last part I don't understand. I though that H(A1) is dependent on th= e=20 > algorithm, not qop. Qop has only influence on the A2 and digest, which ar= e=20 > both calculated in the Diameter Client (SIP Server). See also < > http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue40> >=20 > But even then I don't understand. I think that the Diameter Server does= =20 > has the client-nonces available (they're in the SIP-Authorization AVP, an= d=20 > were used to calculate the request digest !)), and is able to calculate a= =20 > H(A1). Even if MD5-sess was used, it could still calculate H(A1). MD5-ses= s=20 > also has the added advantage that H(A1) could only be used once, which is= =20 > also the reason why draft-sterman-aaa-sip-04.txt doesn't want to use MD5= =20 > unless the message is protected against eavesdropping. Now I see that the Digest-HA1 attribute is present in the SIp-Authenticate= =20 AVP, which probably never saw a cnonce at all, because it's part of the=20 challenge. My mistake was that I thought that it was in SIP-Authorisation= =20 too. This also means that if a server decides to include Digest-Ha1 to assist th= e=20 SIP-server (to avoid that the next packet with the Sip-Authorisation should= =20 be forwarded to the server too), then it should not offer the SIP UA to use= =20 MD5-sess, because that includes client-nonces in A1. Qop is not a problem,= =20 despite paragraph 3 in section 8.5.6.1 of sip-app-07. I agree that if qop is missing and algorithm is MD5, client-nonces aren't= =20 > used at all (backwards compatibility with RFC2069). H(A1) might be stored= =20 > inside the Diameter Client (SIP server) when it's first received, and reu= sed=20 > later on. Is it this that the draft is alluding to ? >=20 > --=20 > Jo Hermans >=20 > "Eagles may soar, but weasels aren't sucked into jet engines"=20 --=20 Jo Hermans www.bluesweb.org "Eagles may soar, but weasels aren't sucked into jet engines" ------=_Part_13_16954606.1113345855892 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Replying on my own question ...

On 4/12/05, Jo Hermans <jo.hermans= @gmail.com> wrote:
I have a problem with paragraph 8.5.6.1 in draft-ietf-aaa-diameter-sip-app-07 , 3th paragraph ("Please note that the expected response ...")

The draft mentions that the expected response calculation can't be done when the SIP UA has sent a expected response based on client nonces. It then mentions that this is the case when the qop-parameter is present in the client request.

That last part I don't understand. I though that H(A1) is dependent on the algorithm, not qop. Qop has only influence on the A2 and digest, which are both calculated in the Diameter Client (SIP Server).  See also <http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue40&= gt;

But even then I don't understand. I think that the Diameter Server does has the client-nonces available (they're in the SIP-Authorization AVP, and were used to calculate the request digest !)), and is able to calculate a H(A1). Even if MD5-sess was used, it could still calculate H(A1). MD5-sess also has the added advantage that H(A1) could only be used once, which is also the reason why draft-sterman-aaa-sip-04.txt doesn't want to use MD5 unless the message is protected against eavesdropping.

Now I see that the Digest-HA1 attribute= is present in the SIp-Authenticate AVP, which probably never saw a cnonce at all, because it's part of the challenge. My mistake was that I thought that it was in SI= P-Authorisation too.

This also means that if a server decides to include Digest-Ha1 to assist the SIP-server (to avoid that the next packet with the Sip-Authorisa= tion should be forwarded to the server too), then it should not offer the S= IP UA to use MD5-sess, because that includes client-nonces in A1.  Qop is not a problem, despite paragraph= 3 in section 8.5.6.1 of sip-app-07.

I agree that if qop is missing and algorithm is MD5, client-nonces aren't used at all (backwards compatibility with RFC2069). H(A1) might be stored inside the Diameter Client (SIP server) when it's first received, and reused later on. Is it this that the draft is alluding to ?

--
Jo Hermans

"Eagles may soar, but weasels aren't suck= ed into jet engines"



--
Jo Hermans
www.bluesweb.org

"Eagles may soar, but = weasels aren't sucked into jet engines" ------=_Part_13_16954606.1113345855892-- From owner-aaa-wg@merit.edu Wed Apr 13 05:14:19 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07865 for ; Wed, 13 Apr 2005 05:14:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7D41E912FB; Wed, 13 Apr 2005 05:14:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C61F912FF; Wed, 13 Apr 2005 05:14:11 -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 E5EE3912FB for ; Wed, 13 Apr 2005 05:14:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D39B55828D; Wed, 13 Apr 2005 05:14:09 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 8EF9258288 for ; Wed, 13 Apr 2005 05:14:09 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 9566D1877; Wed, 13 Apr 2005 05:14:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by testbed9.merit.edu (Postfix) with ESMTP id 1BCE9186D for ; Wed, 13 Apr 2005 05:14:08 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3D9E6O01845; Wed, 13 Apr 2005 12:14:06 +0300 (EET DST) X-Scanned: Wed, 13 Apr 2005 11:59:47 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j3D8xlvM001355; Wed, 13 Apr 2005 11:59:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00NAN3Mk; Wed, 13 Apr 2005 11:59:46 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3D8xiM17355; Wed, 13 Apr 2005 11:59:44 +0300 (EET DST) Received: from [127.0.0.1] ([172.21.39.90]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Apr 2005 11:59:43 +0300 Message-ID: <425CDF7E.6030706@nokia.com> Date: Wed, 13 Apr 2005 11:59:42 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jo Hermans Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue with expected response calculation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2005 08:59:43.0104 (UTC) FILETIME=[221A8800:01C54007] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jo: Thanks for your comment. I agree with you that the paragraph in Section 8.5.6.1 (Note that...) does not make sense again, and it is related to issue 40. It should have been fixed together. Since it seems that we will add support for client generated nonces, there will be new versions of the Diameter SIP app, and at that time we will fix this paragraph, and add the considerations about the MD5-sess you mentioned. Thanks a lot, Miguel Jo Hermans wrote: > Replying on my own question ... > > On 4/12/05, Jo Hermans > wrote: > > I have a problem with paragraph 8.5.6.1 in > draft-ietf-aaa-diameter-sip-app-07 , 3th paragraph ("Please note > that the expected response ...") > > The draft mentions that the expected response calculation can't be > done when the SIP UA has sent a expected response based on client > nonces. It then mentions that this is the case when the > qop-parameter is present in the client request. > > That last part I don't understand. I though that H(A1) is dependent > on the algorithm, not qop. Qop has only influence on the A2 and > digest, which are both calculated in the Diameter Client (SIP > Server). See also > > > But even then I don't understand. I think that the Diameter Server > does has the client-nonces available (they're in the > SIP-Authorization AVP, and were used to calculate the request digest > !)), and is able to calculate a H(A1). Even if MD5-sess was used, it > could still calculate H(A1). MD5-sess also has the added advantage > that H(A1) could only be used once, which is also the reason why > draft-sterman-aaa-sip-04.txt doesn't want to use MD5 unless the > message is protected against eavesdropping. > > > Now I see that the Digest-HA1 attribute is present in the > SIp-Authenticate AVP, which probably never saw a cnonce at all, because > it's part of the challenge. My mistake was that I thought that it was in > SIP-Authorisation too. > > This also means that if a server decides to include Digest-Ha1 to assist > the SIP-server (to avoid that the next packet with the Sip-Authorisation > should be forwarded to the server too), then it should not offer the SIP > UA to use MD5-sess, because that includes client-nonces in A1. Qop is > not a problem, despite paragraph 3 in section 8.5.6.1 > of sip-app-07. > > I agree that if qop is missing and algorithm is MD5, client-nonces > aren't used at all (backwards compatibility with RFC2069). H(A1) > might be stored inside the Diameter Client (SIP server) when it's > first received, and reused later on. Is it this that the draft is > alluding to ? > > -- > Jo Hermans > > "Eagles may soar, but weasels aren't sucked into jet engines" > > > > > -- > Jo Hermans > www.bluesweb.org > > "Eagles may soar, but weasels aren't sucked into jet engines" -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland From genmac@fadmail.com Wed Apr 13 11:14:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04701; Wed, 13 Apr 2005 11:14:41 -0400 (EDT) Received: from pd950a471.dip.t-dialin.net ([217.80.164.113]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLjjW-0001Zj-Gi; Wed, 13 Apr 2005 11:24:52 -0400 Authentication-Results: chimney.es from=premium.bemadden.es; domainkeys=neutral (no sig) X-Originating-IP: [68.64.28.95] Received: from premium.beardsley.es (EHLO premium.borne.es) by premium.nosebleed.es with SMTP; Wed, 13 Apr 2005 17:07:11 +0100 Date: Wed, 13 Apr 2005 09:10:11 -0700 From: "Elliott Goss" To: -announce@ietf.org Cc: -archive@ietf.org, -drafts@ietf.org, -impl-archive@ietf.org, -web-archive@ietf.org, ..@ietf.org, _@ietf.org, a@ietf.org, aaa@ietf.org, aaa-archive@ietf.org, aaa-web-archive@ietf.org, action@ietf.org, adm@ietf.org, admin@ietf.org, administrator@ietf.org Subject: Notification: We offer low rates Message-ID: <112341.7073.genmac@fadmail.com> X-Mailer: Kana Connect 6 X-Spam-Score: 3.3 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Hans Akins to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From ersi@yebox.com Wed Apr 13 11:21:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05103; Wed, 13 Apr 2005 11:21:19 -0400 (EDT) Received: from [221.154.44.109] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLjpw-0001jv-7U; Wed, 13 Apr 2005 11:31:30 -0400 X-Apparently-To: aaa-archive@ietf.org X-Sieve: CMU Sieve 2.2 Received: from bedford.hurdle.pochta.ru ([unix socket]) by milch.broglie.pochta.ru (Cyrus v2.2.3) with LMTPA; Wed, 13 Apr 2005 20:18:16 +0400 Date: Wed, 13 Apr 2005 17:21:16 +0100 From: "Karl Tillman" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: aaa-archive@ietf.org Cc: aaa-web-archive@ietf.org, action@ietf.org, adm@ietf.org, admin@ietf.org, administrator@ietf.org Subject: Approved mortage rate X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Sheryl Cannon to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From xgwqhabqvjwx@yahoo.com Thu Apr 14 00:46:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09691; Thu, 14 Apr 2005 00:46:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLwP4-0007RS-8h; Thu, 14 Apr 2005 00:56:35 -0400 Received: from [210.178.191.5] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DLwF4-0003tS-Ot; Thu, 14 Apr 2005 00:46:16 -0400 Received: from 116.16.80.244 by 210.178.191.5; Wed, 13 Apr 2005 22:35:54 -0600 Message-ID: <%RNDUCCHAR2025@yahoo.com> From: "Darwin Wilkinson" Reply-To: "Darwin Wilkinson" To: aaa-archive@ietf.org Subject: aaa-archive@ietf.org Date: Thu, 14 Apr 2005 03:35:54 -0100 X-Mailer: AOL 1.0 for Windows US sub 722 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--736992139111332521" X-Priority: 3 X-MSMail-Priority: Normal X-IP: 76.134.221.29 X-Spam-Score: 41.5 (+++++++++++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a ----736992139111332521 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Nova pagina 1

#rndnr#

para retirar seu e-mail clique aqui.


http://terra.com.br http://uol.com.br http://msn.co.il h= ttp://msn.com http://msn.com.br http://hotmail.co= m http://superig.c= om.br http://= hotmail.co.il http://hotmail.co= uk http:/= /ig.com.br

 ----736992139111332521-- From mama_briggs3@yahoo.com Thu Apr 14 11:56:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26574; Thu, 14 Apr 2005 11:56:22 -0400 (EDT) Message-Id: <200504141556.LAA26574@ietf.org> Received: from [213.154.93.176] (helo=helimore692.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DM6re-0005Ym-4s; Thu, 14 Apr 2005 12:06:46 -0400 From: "MA BRIGGS" Reply-To: mama_briggs3@yahoo.com To: aaa-archive@ietf.org CC: pana-owner@ietf.org, action@ietf.org, amyk@ietf.org Date: Thu, 14 Apr 2005 17:56:07 +0200 Subject: FROM ME X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 9.5 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable From Mrs Jennifer Briggs=2E To=3A Dear in Christ =2C I am the above named person from Sudan=2E I am married to Mr=2E Greg Briggs who worked with Sudan Consulate in Senegal for nine years before he died in the year 2002=2E We were married for nineteen years with a child=2EMy husband was shot dead when the Sudan People's Libration Army=28SPLA=29attacked our home=2E Before his death=2C we were both born again Christian=2E Since his death=2C I decided not to remarry or get a child outside my matrimonial home which the Bible is against=2EWhen my late husband was alive he left the sum of $3=2E5 Million =28Three million five hundred thousand U=2ES=2EDollars=29 in fixed deposite with one of the local Finance firm here in Dakar Senegal=2E Presently=2C this money is still in the finance firm=2E Recently=2C my Doctor told me that I would not last for the next Four months due to cancer problem=2E The one that disturbs me most is my stroke sickness=2E Having known my condition I decided to donate this fund to a church that will utilize this money accordingly as stated herein=2E I want a church that will use this fund for orphanages=2C widows=2C propagating the word of God and to endeavour that the house of God is maintained=2E The Bible made us to understand that =93Blessed is the hand that Giveth=22 and that =22Givers never Lack=22 I took this decision because of my only Child that will inherit 25% from this money and help to secure a good education & accomodation and also for the sake of God i will like you to take him as your child and as a guidiane to him=2EI don=92t want my husband=92s efforts to be used by unbelievers=2E I don=92t want a situation where this money will be used in an ungodly way=2E This is why I am taking this decision=2E I am not afraid of death hence I know where I am going=2E I know that I am going to be in the bosom of the Lord=2E Exodus 14 VS 14 says th at =93the lord will fight my case and I shall hold my Peace=94=2E I don=92t need any telephone communication in this regard because of my health=2E With God all things are possible=2E As soon as I receive your reply I shall give you the contact of the Finance Firm and my account number both the web site of the Finance Firm here in Dakar-Senegal =2E I will also issue you an Authority letter that will prove you as the present beneficiary of my funds=2E I want you and your family to always pray for me and my son because the lord is my Shephard=2E My happiness is that I lived a life of a worthy to Emulate as a born again Christian=2E Whoever that wants to serve the Lord must serve him in spirit and truth=2E Please always be prayerful all through your life any delay in your reply will give me room in sourcing another church for this same purpose=2EPlease assure me that you will act accordingly as I stated herein=2EYou should contact me throught this alternate email ma=5Fbriggs1=40yahoo=2Efr =3Cmailto=3Ama=5Fbriggs1=40yahoo=2Efr=3E Hoping to receive your reply=2E Remain blessed in the Lord=2E Yours in Christ=2C Mrs=2EJennifer Briggs=2E From kenton@aceinstall.com Thu Apr 14 21:49:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20367 for ; Thu, 14 Apr 2005 21:49:20 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMG7X-00064G-0V for aaa-archive@ietf.org; Thu, 14 Apr 2005 21:59:49 -0400 Received: from wsip-24-248-189-133.ph.ph.cox.net ([24.248.189.133]) by mx2.foretec.com with smtp (Exim 4.24) id 1DMFDw-0006Sn-J4 for aaa-archive@ietf.org; Thu, 14 Apr 2005 21:02:21 -0400 Message-ID: From: "Vanessa J. Smith" To: aaa-archive@ietf.org Subject: =?iso-8859-1?B?V2luZG93cyBYUCAtIDc1JSBPRkY=?= Date: Fri, 15 Apr 2005 01:34:26 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_980C33F1.AFA2C0FA" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0000_980C33F1.AFA2C0FA Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_D4B524E1.812EB182" ------=_NextPart_001_0001_D4B524E1.812EB182 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Access all the software imaginable for extremely low prices! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Visio 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... Please visit us at: http://www.soft-disks.com Best, Vanessa J. Smith _____________________________________________________ To be taken off future campaigns, go here: http://www.soft-disks.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_D4B524E1.812EB182 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Get all the software possible for less!
We sell software 2-6 times cheaper than retail price.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... To visit us go:

http://www.soft-disks.com

Best,
Vanessa J. Smith


_____________________________________________________
To change your mail preferences, go here: http://www.soft-disks.com/uns.htm
_____________________________________________________

------=_NextPart_001_0001_D4B524E1.812EB182-- ------=_NextPart_000_0000_980C33F1.AFA2C0FA-- From owner-aaa-wg@merit.edu Fri Apr 15 07:35:54 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19195 for ; Fri, 15 Apr 2005 07:35:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E02349120D; Fri, 15 Apr 2005 07:35:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADC5F9124B; Fri, 15 Apr 2005 07:35:48 -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 95A949120D for ; Fri, 15 Apr 2005 07:35:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8203B582A3; Fri, 15 Apr 2005 07:35:47 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 6B9AE58290 for ; Fri, 15 Apr 2005 07:35:47 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 510451887; Fri, 15 Apr 2005 07:35:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by testbed9.merit.edu (Postfix) with ESMTP id 26AA61853 for ; Fri, 15 Apr 2005 07:35:46 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BA7668988A for ; Fri, 15 Apr 2005 14:35:42 +0300 (EEST) Message-ID: <425FA712.1020903@kolumbus.fi> Date: Fri, 15 Apr 2005 14:35:46 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: election process padding question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 5.6.4: The election is performed on the responder. The responder compares the Origin-Host received in the CER sent by its peer with its own Origin-Host. If the local Diameter entity's Origin-Host is higher than the peer's, a Win-Election event is issued locally. The comparison proceeds by considering the shorter OctetString to be padded with zeros so that it length is the same as the length of the longer, then performing an octet-by-octet unsigned comparison with the first octet being most significant. Any remaining octets are assumed to have value 0x80. The question is what does the last sentence mean, given that we already stated that padding will be performed so that the lengths match? (Material for an errata, or am I missing something?) From zyaskhcdsgtr@yahoo.com Fri Apr 15 12:05:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16980; Fri, 15 Apr 2005 12:05:20 -0400 (EDT) Received: from c-24-2-76-116.hsd1.ut.comcast.net ([24.2.76.116]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMTU2-0005JY-8V; Fri, 15 Apr 2005 12:15:57 -0400 Received: from 91.15.52.194 by 132.151.6.1; Fri, 15 Apr 2005 09:04:03 -0700 Message-ID: From: "Elsa Kern" Reply-To: "Elsa Kern" To: aaa-archive@ietf.org Subject: aaa-archive@ietf.org Date: Fri, 15 Apr 2005 13:03:03 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--570226617281525250" X-Priority: 3 X-CS-IP: 70.176.48.64 X-Spam-Score: 31.8 (+++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 ----570226617281525250 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Nova pagina 1

= BRASIL      ****       EUROPA     &= nbsp;  ****     EUA

MULTINACIONAL
EM EXPANS=C3O CIA AMERICANA
ASSOCIADA A BANCOS DE INVESTIMENTO
BUSCA PROFISSIONAL EMPREENDEDOR.
 ATUA=C7=C3O EM SUPERVIS=C3O, GERENCIA E ATACADISTA.
  EXCELENTE REMUNERA=C7=C3O E ACESSO A PLANO DE CARREIRA.
CLIQUE AQUI PARA ACESSAR

 para retirar seu e-mail do nosso banco de dados, no caso que n=E3o interesse receber  clique aqui.

 

www.terra.com.br www.uol.com.br www.msn.co.il www.msn.com www.msn.com.br www.hotmail.= com www.superig.= com.br ww= w.hotmail.co.il www.hotmail.c= o.uk w= ww.ig.com.br

 

 ----570226617281525250-- From sybus@doneasy.com Fri Apr 15 17:43:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00887; Fri, 15 Apr 2005 17:43:07 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYky-0003Uv-5y; Fri, 15 Apr 2005 17:53:46 -0400 Received: from [220.94.202.186] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DMYad-0006Lm-CI; Fri, 15 Apr 2005 17:43:04 -0400 Authentication-Results: embouchure.es from=premium.danger.es; domainkeys=neutral (no sig) X-Originating-IP: [193.240.199.180] Received: from premium.grata.es (EHLO premium.latent.es) by premium.befell.es with SMTP; Fri, 15 Apr 2005 17:32:30 -0500 Date: Fri, 15 Apr 2005 20:36:30 -0200 From: "Andrew Wynn" To: aaa-archive@ietf.org Cc: aaa-web-archive@ietf.org, action@ietf.org, adm@ietf.org, admin@ietf.org, administrator@ietf.org, adslmib@ietf.org, adslmib-web-archive@ietf.org, afts@ietf.org, agenda@ietf.org, aheugavt-admin@ietf.org, aids@ietf.org, all-avt@ietf.org, all-ietf@ietf.org, amoby@ietf.org, amyk@ietf.org Subject: Approved mortage rate Message-ID: <114041.2154.sybus@doneasy.com> X-Mailer: Kana Connect 6 X-Spam-Score: 3.3 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Jess Hearn to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From clarrie@acadiacom.net Fri Apr 15 18:06:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03744 for ; Fri, 15 Apr 2005 18:06:30 -0400 (EDT) Received: from pcp0011228657pcs.hntgtn01.in.comcast.net ([69.245.225.111]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMZ7Y-0004qZ-LW for aaa-archive@ietf.org; Fri, 15 Apr 2005 18:17:10 -0400 Message-ID: From: "Vanessa J. Smith" To: aaa-archive@ietf.org Subject: =?iso-8859-1?B?T2ZmaWNlIHNvZnR3YXJlIC0gd2hvbGVzYWxlIHByaWNl?= Date: Sat, 16 Apr 2005 00:31:35 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_7D72F7F4.F6E31DAE" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0000_7D72F7F4.F6E31DAE Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_D56424F6.2AE81156" ------=_NextPart_001_0001_D56424F6.2AE81156 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get access to all the software you ever imagined for bottom prices! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... To visit us go: http://www.soft-disks.com Best, Vanessa J. Smith _____________________________________________________ To stop further mailings, go here: http://www.soft-disks.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_D56424F6.2AE81156 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Access all the popular software you ever imagined for extremely low prices!
We sell software 2-6 times cheaper than retail price.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Visio 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... For full list of products go:

http://www.soft-disks.com

Best regards,
Vanessa J. Smith


_____________________________________________________
To stop further mailings, go: http://www.soft-disks.com/uns.htm
_____________________________________________________

------=_NextPart_001_0001_D56424F6.2AE81156-- ------=_NextPart_000_0000_7D72F7F4.F6E31DAE-- From croton@doramail.com Fri Apr 15 22:35:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08239; Fri, 15 Apr 2005 22:35:22 -0400 (EDT) Received: from [211.204.131.212] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMdJq-0001Ls-0s; Fri, 15 Apr 2005 22:46:04 -0400 Authentication-Results: diagnosable.es from=premium.habitual.es; domainkeys=neutral (no sig) X-Originating-IP: [191.110.160.98] Received: from premium.digestion.es (EHLO premium.portend.es) by premium.coin.es with SMTP; Sat, 16 Apr 2005 08:38:05 +0500 Date: Sat, 16 Apr 2005 04:31:05 +0100 From: "Saul Tovar" To: -announce@ietf.org Cc: -archive@ietf.org, -drafts@ietf.org, -impl-archive@ietf.org, -web-archive@ietf.org, ..@ietf.org, _@ietf.org, a@ietf.org, aaa@ietf.org, aaa-archive@ietf.org, aaa-web-archive@ietf.org, action@ietf.org, adm@ietf.org, admin@ietf.org, administrator@ietf.org Subject: Need a low mortage rate? Message-ID: <112641.1479.croton@doramail.com> X-Mailer: Kana Connect 6 X-Spam-Score: 5.8 (+++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Natalia Dickens to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s.