To: l2vpn-web-archive@ietf.org
Subject: Your New Rate is 3.54%
Date: Wed, 08 Sep 2004 00:46:21 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--265798176655483410"
X-Priority: 3
X-CS-IP: 94.144.63.32
X-Spam-Score: 13.6 (+++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: d6b246023072368de71562c0ab503126
----265798176655483410
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable
Tue, 07 Sep 2004 23:47:21 -0600
EMail ID: l2vpn-web-archive@ietf.org
CLIENT#: 256-9569-446
Dear Sir/Madam;
Upon completion of our 1 minute registration for=
m we will be able to
offer you a new rate on the re-finance of your mortgage.
One of our=
Brokers will be in contact with you shortly to answer any questions you m=
ay have.
Registration Application:
http://entirefinance.com=
/?partid=3Dpopyam
Sincerely;
Paulette Voss
Loans/Mortgage=
Department
Consultant
Broker ID: 6523-327
=
N0T Y0U? http://entirefinance.com/st.html
----265798176655483410--
From VPPYLXZYOD@snet.net Wed Sep 8 13:49:12 2004
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 NAA01225;
Wed, 8 Sep 2004 13:49:12 -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 1C56cv-0005eO-Ga; Wed, 08 Sep 2004 13:53:03 -0400
Received: from stouen-1-81-57-207-159.fbx.proxad.net ([81.57.207.159])
by mx2.foretec.com with smtp (Exim 4.24)
id 1C56ZC-0004np-FG; Wed, 08 Sep 2004 13:49:11 -0400
Message-ID: <7661299909960096867.19jbs42200903y@atl.mindspring.com>
Received: from 156.155.150.192 by kri819-j698.z613.atl.mindspring.com with DAV;
Wed, 08 Sep 2004 12:44:48 -0600
Reply-To: "Rolex At $99."
From: "Rolex At $99."
To:
Subject: Bu.y 5 Rolex and get shipping Free !!-Eap-archive lk 7 yvmf
Date: Wed, 08 Sep 2004 11:41:48 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--931856863463311"
X-Spam-Score: 4.1 (++++)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
----931856863463311
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Hello,
We all want to wear SWISS WATCHS,
they are expensive-we all know that,
Now we have effordable Replica's--
of following brands available at very cheaper prices.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Cartier
Bvlgari
Frank Muller
Chopard
Patek Philippe
Breguet
Audemars Piguet
Blancpain
Jaeger-lecoultre
Chronoswiss
Omega
Tag Heuer
Ikepod
Eberhard
Tudor
Sinn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
AND MORE
http://replicacollection.info/index.php?ref=3Dhp
Italian Crafted Rolex - Complete Watch Store
Reliable Service and Support
Check Here For More Information
http://replicacollection.info/index.php?ref=3Dhp
Regards
Garland Ray
marco confucian fluoridate until antecedent armature soft sic unitarian mi=
llennia countryman baseband amphioxis extinguish certiorari tore collatera=
l crib tramway malaprop smokehouse ciliate hom cinnamon clime exclamatory =
calamitous statistician egress iowa yogurt trioxide succumb puckish jules =
gentility bratwurst carrion coquette brutal epidemiology herald invasion s=
nakebird sawtooth cling dandy rhinestone lithology exhibition dignitary lu=
nch mode darpa botulism doctrinaire girlie slave abominate lampoon bootleg=
ging backpack beauteous bela mother koala banana mcfarland suzuki sniffle =
abominable brouhaha augustan crockery horsefly watergate cochineal anabel =
exacerbate bordello unite freya demitting akers creedal bootes infancy oni=
on experimentation sanderson coralberry clinch nelson ridiculous wiretappi=
ng aviatrix stannic imprecision necromancer dharma menopause psaltery weat=
herproof hibachi c chuckle secrete bromley fabric local creekside aloof bi=
bb bagel picnic bean alive bathos form bedevil gather damask caprice expre=
ssible yond ha primitive janitor bilingual nonsensic sluggish sibilant whi=
nny bust denigrate dietrich tease calcine analogous embargoes october bene=
ficial anticipate wipe mesh magna miscreant quartet sinewy slacken angela =
atom islamic charlemagne diehard spectrum troop copybook groundskeep brand=
delphinium shapiro afro lugging siliceous parsimony proud excrescent meis=
tersinger madrid amputee industry tacit beefsteak forbes convoke corruptio=
n hoy concise circumcircle cherry chalcocite blowback leeway porpoise grah=
am isaac oldster cellar barbell teamwork augend dole campsite panty opprob=
rium terramycin trundle calorimeter atop jejunum hilt defrost resorcinol b=
reakaway sammy spiegel adept porosity chili circumsphere depress capitolin=
e medicinal comedy deltoid nucleant cottonseed ephemeral profundity andrei=
adjust draftee device grandiose isolate bedevil peruse coax fast bottom c=
rash casteth laughter transcription folly astringent centerpiece denver cu=
b appeasable coercive curricula ocean accidental bumptious expanse interfe=
rometer cater eider canterelle chaparral platelet builtin simmons einstein=
archangel claremont pervasive dominic complaint jasper buddhism alkaline =
life virtuosity bogota sherry meistersinger cayley phone adler blank deter=
gent bakersfield glum ripen dublin omicron counteract workpiece highland d=
oe
----931856863463311--
From lumnech@onlinesoft.com Wed Sep 8 20:34:55 2004
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 UAA06708;
Wed, 8 Sep 2004 20:34:55 -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 1C5Cxb-0006lo-WE; Wed, 08 Sep 2004 20:38:50 -0400
Received: from [61.55.221.43] (helo=65.246.255.50)
by mx2.foretec.com with smtp (Exim 4.24)
id 1C5Ctl-0006hd-DX; Wed, 08 Sep 2004 20:34:50 -0400
Received: from zxcmn4.e.pi.net([61.55.221.43]) by yhfp9226-x.pi.net with Microsoft SMTPSVC(5.0.46242.70794);
Wed, 08 Sep 2004 22:31:31 -0200
Received: from ecpntjz.zs@pi.net (147.192.202.200)
by azurw204738.wub.@pi.net with QMQP; Wed, 08 Sep 2004 17:25:31 -0700
X-MIME-Autoconverted: Yes
Discarded-X400-MTS-Extensions: Yes
Alternate-Recipient: Allowed
Xref: qpxsnkdjllqgoatfkzg
Reply-To: "Otis_Houston"
From: "Otis_Houston"
To: seamoby@ietf.org
Cc: bpana@ietf.org, owner-ietf-outbound@ietf.org, entmib-request@ietf.org,
xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org,
eap-archive@ietf.org, r-wg-admin@ietf.org,
ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org,
cfrg-request@ietf.org, sg@ietf.org
Subject: Responding back to your application
Date: Thu, 09 Sep 2004 01:25:31 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--0552522088073560374"
Message-Id:
X-Spam-Score: 7.3 (+++++++)
X-Spam-Flag: YES
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
----0552522088073560374
Content-Type: text/html;
charset="iso-7229-1"
Content-Transfer-Encoding: 7Bit
Dear Applicant,
Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.
Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55
We look forward to hearing from you.
Regards,
Otis_Houston
Senior Account Manager
Webber Financial Association
----0552522088073560374--
From Wade_Engquist@gvc.net Wed Sep 8 23:02:17 2004
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 XAA25809
for ; Wed, 8 Sep 2004 23:02:17 -0400 (EDT)
Message-Id: <200409090302.XAA25809@ietf.org>
Received: from [201.0.58.23] (helo=201-0-58-23.dsl.telesp.net.br)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C5FGG-0000Qm-6X
for eap-archive@ietf.org; Wed, 08 Sep 2004 23:06:14 -0400
From: "Gina Heintz"
To: eap-archive@ietf.org
Subject: high quality
Date: Thu, 09 Sep 2004 07:56:17 +0400
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 6.4 (++++++)
X-Spam-Flag: YES
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
The frigate skirted the south-east coast of America with =
great rapidity
no msg
But, thanks to the nationality of the victim of the shock, thanks to the r=
eputation of the company to which the vessel belonged, the circumstance be=
came extensively circulated. But if there should remain two or more who ha=
ve equal votes, the Senate shall choose from them by ballot the Vice Presi=
dent?=20
From RYSPCQJ@adelphia.net Thu Sep 9 01:43:25 2004
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 BAA05520
for ; Thu, 9 Sep 2004 01:43:25 -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 1C5HmC-0002zt-A0
for eap-archive@ietf.org; Thu, 09 Sep 2004 01:47:21 -0400
Received: from [199.237.53.2] (helo=BC09311)
by mx2.foretec.com with smtp (Exim 4.24)
id 1C5HiN-0004Z5-UZ
for eap-archive@ietf.org; Thu, 09 Sep 2004 01:43:24 -0400
X-Message-Info: VZVXzymT230zrMdg/uCMoCYOhfAGVdZNNbbyPCYe888IGM
Received: from earl-t686.perky.greenapple.com (142.136.53.216) by ooe6-isx009.greenapple.com with Microsoft SMTPSVC(5.0.2195.6824);
Thu, 09 Sep 2004 12:34:36 +0600
From: Cara Dean
To: eamoby@ietf.org
Subject: The most valuable onljne pha.rmeci site! Cljck now! broadway
Date: Thu, 09 Sep 2004 05:37:36 -0100 EST
Message-ID: <63633794052735107952.30.05@scoop-c27.greenapple.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--328785983973912877"
X-Spam-Score: 9.3 (+++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
----328785983973912877
Content-Type: text/html;
Content-Transfer-Encoding: 7Bit
Hi and welcome to our phhaemeci!
We appreciate the time you spend while looking for
new and better phhaemeci sites over the net, so we
decided to let you know about our site, our phhaemeci.
As you can see, we got large verjety of products. You are
more then welcomed to enter and view our site.
signora imbroglio uon sabscrjb roentgen
seaward epileptic geodesic iraq loose sangaree gastronomy. peepy carbonate psychopomp ellis lance transduction. mutton janitor jon. glottal clerk dosage.
castro bengali milan porcine phyllis descriptive. tertiary there illumine bib cowpoke pratt attendee blueprint. trickle castillo knick decent coincident plagiarism heir. collector doric circumference fortin catechism. hothead lane memorandum gregarious clique.
cozen halcyon allot. venture edison conjugacy diminution venture successful.
oilman vilify apropos. down laudatory obfuscatory conferred venom. bergland tory vie bavaria coeditor urchin resultant.
earmark billboard ketchup compleat calibrate viva cadaver. clang dairylea necromancy connive snagging. eggplant muskoxen susie airmen.
----328785983973912877--
From eap-admin@frascone.com Thu Sep 9 07:34:08 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08797
for ; Thu, 9 Sep 2004 07:34:07 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id D4E0521793; Thu, 9 Sep 2004 07:34:05 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id AF77E2078A; Thu, 9 Sep 2004 07:34:02 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 8128B2078A
for ; Thu, 9 Sep 2004 07:33:41 -0400 (EDT)
Received: from p2.piuha.net (p2.piuha.net [131.160.192.2])
by mail.frascone.com (Postfix) with ESMTP id D480D203D8
for ; Thu, 9 Sep 2004 07:33:39 -0400 (EDT)
Received: from piuha.net (p2.piuha.net [131.160.192.2])
by p2.piuha.net (Postfix) with ESMTP id 867ED8986C
for ; Thu, 9 Sep 2004 14:33:37 +0300 (EEST)
Message-ID: <41403F5E.5080503@piuha.net>
From: Jari Arkko
Reply-To: jari.arkko@piuha.net
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "eap@frascone.com"
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] eap identity request and radius user-name attribute
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Thu, 09 Sep 2004 14:32:46 +0300
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
While discussing the use of IKEv2 in 3G networks with
my colleagues, a question relating to EAP Identity
Responses and RADIUS/Diameter EAP came up.
As background, IKEv2 specification says that the
EAP identity request/response exchange should
not be used. The identity of the client is
transported in the IKEv2 payloads instead.
The question is how this identifier is carried
to the AAA server. Presumably, the identifier
should go to the User-Name attribute in RADIUS.
According to RFC 3579, it is possible to set the
EAP-Payload attribute to an empty string, representing
EAP-Start. But what do typical AAA servers do in
this case, will they rely on the username from the
User-Name attribute, or issue an EAP Identity Request?
The latter would seem to be a violation of the
IKEv2 specifications. I think our EAP state machines
allow both behaviors, but I'm curious what the current
behaviour is in existing implementations.
Secondly, it was suggested that the IKEv2
node could synthethise an EAP Identity Response
packet and send that along in the EAP-Payload
attribute. That doesn't seem quite right either,
but would this break something? Are there EAP
methods that integrity protect EAP messages exchanged
earlier in the process?
--Jari
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Thu Sep 9 12:29:06 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01451
for ; Thu, 9 Sep 2004 12:29:05 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 858A1212B9; Thu, 9 Sep 2004 12:29:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 3E58520F89; Thu, 9 Sep 2004 12:29:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 1981020F89
for ; Thu, 9 Sep 2004 12:28:33 -0400 (EDT)
Received: from intotoinc.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
by mail.frascone.com (Postfix) with ESMTP id 2B4EB20B2F
for ; Thu, 9 Sep 2004 12:28:31 -0400 (EDT)
Received: from SriniSony ([10.1.5.111])
by intotoinc.com (8.12.5/8.12.5) with SMTP id i89GSf9D015666;
Thu, 9 Sep 2004 09:28:41 -0700
Message-ID: <00fb01c4968a$061fd820$0301010a@SriniSony>
From: "Srinivasa Rao Addepalli"
To: ,
References: <41403F5E.5080503@piuha.net>
Subject: Re: [eap] eap identity request and radius user-name attribute
Organization: Intoto Inc
MIME-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Thu, 9 Sep 2004 09:28:22 -0700
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
We were doing similar brain-storming recently among us internally.
In wireless scenario (802.1x), Identity is not known to the
authenticator (Access Point, in this case) and in this case, EAP-Start
message can be sent to the RADIUS Server, which starts with
EAP-Identity phase.
In case of IKEv2, identity is already known and we were also not sure
whether EAP-Identity request would be honored by IKEv2 clients.
So, we finally decided to frame EAP-Identity Response (fake it) with
in Authenticator (Node running IKEv2 server) and send it via
RADIUS Access request to the RADIUS Server.
Our understanding is that, RADIUS Servers dont' start with
EAP-Identity phase, if it knows the Identity of the peer. It is also our
understanding that, EAP-Identity response is accepted by the
RADIUS Servers, even if it did not initiate it. We are yet to convince
ourselves that this is the behaviour of all RADIUS Servers.
Srini
Intoto Inc.
www.intoto.com
----- Original Message -----
From: "Jari Arkko"
To:
Sent: Thursday, September 09, 2004 4:32 AM
Subject: [eap] eap identity request and radius user-name attribute
>
> While discussing the use of IKEv2 in 3G networks with
> my colleagues, a question relating to EAP Identity
> Responses and RADIUS/Diameter EAP came up.
>
> As background, IKEv2 specification says that the
> EAP identity request/response exchange should
> not be used. The identity of the client is
> transported in the IKEv2 payloads instead.
>
> The question is how this identifier is carried
> to the AAA server. Presumably, the identifier
> should go to the User-Name attribute in RADIUS.
>
> According to RFC 3579, it is possible to set the
> EAP-Payload attribute to an empty string, representing
> EAP-Start. But what do typical AAA servers do in
> this case, will they rely on the username from the
> User-Name attribute, or issue an EAP Identity Request?
> The latter would seem to be a violation of the
> IKEv2 specifications. I think our EAP state machines
> allow both behaviors, but I'm curious what the current
> behaviour is in existing implementations.
>
> Secondly, it was suggested that the IKEv2
> node could synthethise an EAP Identity Response
> packet and send that along in the EAP-Payload
> attribute. That doesn't seem quite right either,
> but would this break something? Are there EAP
> methods that integrity protect EAP messages exchanged
> earlier in the process?
>
> --Jari
>
> _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Thu Sep 9 16:13:08 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20937
for ; Thu, 9 Sep 2004 16:13:08 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 0989221C1B; Thu, 9 Sep 2004 16:13:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id B2CF921C10; Thu, 9 Sep 2004 16:13:02 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id E2FE121C10
for ; Thu, 9 Sep 2004 16:12:12 -0400 (EDT)
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195])
by mail.frascone.com (Postfix) with ESMTP id 2F51320F73
for ; Thu, 9 Sep 2004 16:12:11 -0400 (EDT)
Received: by mproxy.gmail.com with SMTP id 77so79987rnk
for ; Thu, 09 Sep 2004 13:12:07 -0700 (PDT)
Received: by 10.38.75.14 with SMTP id x14mr137608rna;
Thu, 09 Sep 2004 13:12:07 -0700 (PDT)
Received: by 10.38.15.20 with HTTP; Thu, 9 Sep 2004 13:12:07 -0700 (PDT)
Message-ID:
From: Clint Chaplin
Reply-To: Clint Chaplin
To: eap@frascone.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] Test
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Thu, 9 Sep 2004 13:12:07 -0700
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
Ping
Sorry.....
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Fri Sep 10 03:29:09 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29931
for ; Fri, 10 Sep 2004 03:29:08 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 628E51FD6E; Fri, 10 Sep 2004 03:29:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 09D6A1FEA6; Fri, 10 Sep 2004 03:29:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 0A64B1FEA6
for ; Fri, 10 Sep 2004 03:28:23 -0400 (EDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16])
by mail.frascone.com (Postfix) with ESMTP id E33351FD6E
for ; Fri, 10 Sep 2004 03:28:20 -0400 (EDT)
Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0);
Fri, 10 Sep 2004 09:28:34 +0200
Received: from [10.193.167.121] ([10.193.167.121]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747);
Fri, 10 Sep 2004 09:28:13 +0200
Message-ID: <4141579F.8070501@rd.francetelecom.fr>
From: Florent Bersani
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nicolas Williams
Cc: Thomas Otto , eap@frascone.com
Subject: Re: [eap] Re: SHA-0 Broken
References: <200408172353.45203.t.otto@sharevolution.de> <20040817221238.GA1295@binky.central.sun.com>
In-Reply-To: <20040817221238.GA1295@binky.central.sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2004 07:28:13.0620 (UTC) FILETIME=[BB4D7F40:01C49707]
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Fri, 10 Sep 2004 09:28:31 +0200
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
Nicolas Williams wrote:
> <>
>
>>key and takes as underlying crypto primitive AES. Nothing more, just AES.
>>More precisely, AES-128 is used for
>>* mutual authentication
>>* session key derivation (via modified counter mode)
>>* encrypted communication through the secure tunnel
>> (aes in eax mode, hash is OMAC)
>>
>>
> Have a look at EAP-PSK: This is an EAP method which is based on a
> pre-shared
>
>
>And what if AES is broken tomorrow? Inpractical attacks exist, but do
>they cast a shadow on AES' future?
>
>
See Section 2.2 of EAP-PSK:
"Other block ciphers could easily be proposed for EAP-PSK, as it does
not intricately depend on AES-128. The only parameters of AES-128 that
EAP-PSK depends on, are its block size (16 bytes) and its key size (16
bytes). For the sake of simplicity, it has however been chosen to
restrict to a single mandatory block cipher and not allow the
negotiation of other block ciphers. In case AES-128 is deprecated for
security reasons, EAP-PSK should also be deprecated and a cut-and-paste
EAP-PSK' should be defined with another block cipher. This EAP-PSK'
should not be backward compatible with EAP-PSK because of the security
issues with AES-128. EAP-PSK' should therefore use a different
EAP-Request/Response Type number. With the EAP-Request/Response Type
number space structure defined in [2] (Aboba, B., Blunk, L., Vollbrecht,
J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol
(EAP), June 2004). <#RFC3748>, this should not be a problem."
>Why EAX? Why not GCM?
>
>
See Section 2.2.3 of EAP-PSK
"EAX was mainly chosen because:
* It strongly relies on OMAC in its design and OMAC1, a variant of
OMAC, had already been chosen in EAP-PSK for the authentication part.
* Its design is simple.
* It enjoys a security proof.
* It is free of any Intellectual Property Rights claims."
Earlier version of EAP-PSK mentioned in Section 2.2.3:
"There are currently many other proposed modes for authenticated
encryption with associated data - including Intellectual Property Rights
free ones, like CCM, CWC or GCM (please refer to the NIST "Modes of
operation for symmetric key block ciphers" web page
for more details)."
As a matter of fact I know one of the GCM designers and I appreciate GCM
very very much.
It is true that EAP-PSK could use GMAC instead of OMAC and GCM instead
of EAX, which would probably improve the performance of some
computations (a factor 2 could be expected from software benchmarks).
OMAC was chosen because it seemed to have the favors of NIST and at that
time GCM was at its beginnings.
I did not receive many requests to change the modes of operation, that's
why given the point where EAP-PSK is now, I am reluctant to make
changes... but that could change if I feel compelling arguments to do so.
Any comments welcome,
Florent
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Fri Sep 10 03:32:05 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00074
for ; Fri, 10 Sep 2004 03:32:05 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 94B1F205E9; Fri, 10 Sep 2004 03:32:05 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 4AE351FEAF; Fri, 10 Sep 2004 03:32:02 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 1C8351FEAF
for ; Fri, 10 Sep 2004 03:31:45 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15])
by mail.frascone.com (Postfix) with ESMTP id 033DE1FD6E
for ; Fri, 10 Sep 2004 03:31:43 -0400 (EDT)
Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0);
Fri, 10 Sep 2004 09:31:58 +0200
Received: from [10.193.167.121] ([10.193.167.121]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747);
Fri, 10 Sep 2004 09:31:37 +0200
Message-ID: <4141586A.7010809@rd.francetelecom.fr>
From: Florent Bersani
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mohamad Badra
Cc: Thomas Otto , eap@frascone.com
Subject: Re: [eap] Re: SHA-0 Broken
References: <200408172353.45203.t.otto@sharevolution.de> <4123202A.4070303@enst.fr>
In-Reply-To: <4123202A.4070303@enst.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2004 07:31:37.0375 (UTC) FILETIME=[34C00AF0:01C49708]
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Fri, 10 Sep 2004 09:31:54 +0200
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
Mohamad Badra wrote:
>
> I am not opposed to any protocol. Let me answer you by a question: why
> I have to create 'new' one? Why I shall create a new protocol whereas
> I already have the same services if I partially or if I simplify the
> use of IKEv2 or TLS?
>
The IMHO interesting question I asked you and that you apparently
avoided to answer technically was: "why was IKEv2 invented since we
already had TLS"?
I do not have definitive answers as I am currently working on such
topics but I believe that an open-minded reflexion with scientific
arguments on this question may bring many insights.
Florent, who, before taking winners, like to understand why they have
won ;-)
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From DonnyacmMyrick@nfdc.net Fri Sep 10 06:55:30 2004
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 GAA12903;
Fri, 10 Sep 2004 06:55:29 -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 1C5j82-0003H2-Qb; Fri, 10 Sep 2004 06:59:43 -0400
Received: from 62-43-10-43.user.ono.com ([62.43.10.43])
by mx2.foretec.com with smtp (Exim 4.24)
id 1C5j3k-0000cq-SS; Fri, 10 Sep 2004 06:55:17 -0400
X-Message-Info: daob66F6798GZ4ThThWG81vKRG57crxVMAxlNT1C07
Received: from mail pickup service by 62.43.10.43 with Microsoft SMTPSVC;
Fri, 10 Sep 2004 04:52:46 -0700
Content-Class: urn:content-classes:message
Language: English
X-MIME-Autoconverted: Yes
Approved: Yes (schoolmate@superonline.com)
Reply-To: "Eula Guthrie"
From: "Eula Guthrie"
To: ldap-dir@ietf.org
Cc: l2vpn-web-archive@ietf.org, iab-wireless-workshop@ietf.org,
seamoby@ietf.org, bpana@ietf.org, owner-ietf-outbound@ietf.org,
entmib-request@ietf.org, xmldsig-archive@ietf.org,
rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org,
r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org,
rddp-web-archive@ietf.org
Subject: Online Notification: You've Been Approved
Date: Fri, 10 Sep 2004 06:47:46 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--25333824690203263"
Message-Id:
X-Spam-Score: 4.0 (++++)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
----25333824690203263
Content-Type: text/html;
charset="iso-3130-6"
Content-Transfer-Encoding: 7Bit
Dear Applicant,
Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.
Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55
We look forward to hearing from you.
Regards,
Eula Guthrie
Senior Account Manager
Webber Financial Association
----25333824690203263--
From AaronEpson@bookpeddlers.com Fri Sep 10 10:57:51 2004
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 KAA03750
for ; Fri, 10 Sep 2004 10:57:51 -0400 (EDT)
Message-Id: <200409101457.KAA03750@ietf.org>
Received: from [221.141.213.101] (helo=132.151.6.1)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C5mub-0008E5-Jx
for eap-archive@ietf.org; Fri, 10 Sep 2004 11:02:07 -0400
From: "Morlee Mccory"
To: eap-archive@ietf.org
Subject: please
Date: Fri, 10 Sep 2004 13:56:49 -0200
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 6.1 (++++++)
X-Spam-Flag: YES
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: quoted-printable
So when the frigate had been armed for a long campaign, a=
nd provided with formidable fishing apparatus, no one could tell what cour=
se to pursue
Discontinue
The officers of the quarter-deck hurried to the after-part of the vessel? =
Suddenly his arm straightened, and the harpoon was thrown; I heard the son=
orous stroke of the weapon, which seemed to have struck a hard body!!=20
From eap-admin@frascone.com Fri Sep 10 11:55:05 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08603
for ; Fri, 10 Sep 2004 11:55:05 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 6A90C2084E; Fri, 10 Sep 2004 11:55:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id F13EA20864; Fri, 10 Sep 2004 11:55:02 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id DA4C22084E
for ; Fri, 10 Sep 2004 11:54:55 -0400 (EDT)
Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16])
by mail.frascone.com (Postfix) with ESMTP id 49B2A206DD
for ; Fri, 10 Sep 2004 11:54:54 -0400 (EDT)
Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12])
(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
(Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK))
by smtp2.enst.fr (Postfix) with ESMTP
id 635CE53C70; Fri, 10 Sep 2004 17:54:48 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by revolutions.enst.fr (Postfix) with ESMTP id DC0D011AC37;
Fri, 10 Sep 2004 17:54:47 +0200 (CEST)
Received: from revolutions.enst.fr ([127.0.0.1])
by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 25608-04; Fri, 10 Sep 2004 17:54:47 +0200 (CEST)
Received: from email.enst.fr (muse.enst.fr [137.194.2.33])
by revolutions.enst.fr (Postfix) with ESMTP id 8435A11AC33;
Fri, 10 Sep 2004 17:54:47 +0200 (CEST)
Received: from enst.fr (akkar.enst.fr [137.194.164.28])
by email.enst.fr (8.9.3/8.9.3) with ESMTP id RAA16396;
Fri, 10 Sep 2004 17:54:46 +0200 (CEST)
Message-ID: <4141CE47.2020201@enst.fr>
From: Mohamad Badra
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Florent Bersani
Cc: Thomas Otto , eap@frascone.com
Subject: Re: [eap] Re: SHA-0 Broken
References: <200408172353.45203.t.otto@sharevolution.de> <4123202A.4070303@enst.fr> <4141586A.7010809@rd.francetelecom.fr>
In-Reply-To: <4141586A.7010809@rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at enst.fr
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Fri, 10 Sep 2004 17:54:47 +0200
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
Florent Bersani wrote:
> The IMHO interesting question I asked you and that you apparently
> avoided to answer technically was: "why was IKEv2 invented since we
> already had TLS"?
I don't like to answer by a technical question I posted it three months
ago, but it may be a good idea to repeat it here. "Why have we to adopt
or to add new security mechanisms since we had two very *well studied*
and *widely implemented* protocols such as IPSec and TLS?".
The real differences between the TLS and IKEv2 come from the
distinguished requirements of several architectures (included Fixed and
Wireless) and applications. TLS was first developed to answer specific
needs of client/server applications (such as credit card number) where
the authentication was just from the server side. IKE and specially
IKEv2 has different audience in the network architectures to answer a
symmetric initiator/responder connexions where the two communicators
have the same authentication methods. Actually, these two protocols are
merging with their cryptographic and authentication part: they both
integrate PSK authentication, Identity Protection, PFS, fast
negotiation, etc. A lot of work was already done in the IPSec and TLS
IETF WG to produce a secure, flexible and fast security protocol. (Add
what do you want to these three adjectives ;-) ).
IMHO, a new defined protocol is welcome if, and only if *it can prove*
its advantages over TLS and IKEv2.
Badra
P.S. If I didn't answer you properly, please forward your question to
IPSec and TLS mailing list, maybe you will get more info about that.
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From Kayricha_Donahey@fourseasonsmaid.com Sun Sep 12 13:20:11 2004
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 NAA28428
for ; Sun, 12 Sep 2004 13:20:11 -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 1C6Y5t-0004aJ-BW
for eap-archive@ietf.org; Sun, 12 Sep 2004 13:24:55 -0400
Received: from ppp-66-138-240-181.dialup.hrlntx.swbell.net ([66.138.240.181])
by mx2.foretec.com with smtp (Exim 4.24)
id 1C6Y1L-0004VZ-6N
for eap-archive@ietf.org; Sun, 12 Sep 2004 13:20:11 -0400
Subject: Great news
From: "Calv Milot"
To: eap-archive@ietf.org
Date: Sun, 12 Sep 2004 11:20:07 -0700
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-Id:
X-Spam-Score: 6.1 (++++++)
X-Spam-Flag: YES
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
The judicial power of the United States, shall be vested =
in one Supreme Court, and in such inferior courts as the Congress may from=
time to time ordain and establish
<=
/a>
no msg
In virtue of my office as Assistant Professor in the Museum of Natural His=
tory in Paris, the French Government had attached me to that expedition:=20=
From armonk.468301jab@outastep.com Sun Sep 12 21:54:05 2004
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 VAA28102;
Sun, 12 Sep 2004 21:54:05 -0400 (EDT)
Message-Id: <200409130154.VAA28102@ietf.org>
Received: from r253017198.resnet.cornell.edu ([128.253.17.198])
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C6g7I-00044x-P8; Sun, 12 Sep 2004 21:58:53 -0400
Received: from aionedispensarysawtimber70 (comma[168.18.50.217])
by 128.253.17.198 (ehhfu00) with SMTP
id <594161011712pc19ck>
(Authid: Tara$924$Caudill);
Mon, 13 Sep 2004 05:48:30 +0400
Approved: Yes (Phyllis.Todd@kpmg.com)
Distribution: gut calibre
Prevent-NonDelivery-Report: Yes
Reply-To: "Sheryl Zamora"
From: "Sheryl Zamora"
To: rmt-request@ietf.org
Cc: simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org,
ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org,
cfrg-request@ietf.org, sg@ietf.org, megaco-admin@ietf.org,
nemo-request@ietf.org
Subject: New Account Activation
Date: Mon, 13 Sep 2004 06:42:30 +0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--739607649387625"
X-Spam-Score: 5.0 (+++++)
X-Spam-Flag: YES
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
----739607649387625
Content-Type: text/html;
charset="iso-9787-3"
Content-Transfer-Encoding: 7Bit
Dear Applicant,
Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.
Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55
We look forward to hearing from you.
Regards,
Sheryl Zamora
Senior Account Manager
Webber Financial Association
----739607649387625--
From WSXDVCJBZT@hotmail.com Mon Sep 13 07:55:19 2004
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 HAA19953;
Mon, 13 Sep 2004 07:55:19 -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 1C6pVD-0005xV-ER; Mon, 13 Sep 2004 08:00:11 -0400
Received: from [221.139.235.49] (helo=65.246.255.50)
by mx2.foretec.com with smtp (Exim 4.24)
id 1C6pQU-0003KQ-8W; Mon, 13 Sep 2004 07:55:19 -0400
Received: from 170.240.68.42 by web134.mail.yahoo.com; Mon, 13 Sep 2004 11:47:05 -0100
Message-ID:
From: "Priscilla Alford"
To: e3@ietf.org
Subject: Order#492
Date: Mon, 13 Sep 2004 13:48:05 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--17772265206886086"
X-CS-IP: 250.208.184.176
X-Spam-Score: 29.3 (+++++++++++++++++++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
----17772265206886086
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable
WIr: 007-123
----17772265206886086--
From Giavani_Andes@cdoctor.com Tue Sep 14 01:52:22 2004
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 BAA18867
for ; Tue, 14 Sep 2004 01:52:22 -0400 (EDT)
Message-Id: <200409140552.BAA18867@ietf.org>
Received: from [220.69.110.145] (helo=132.151.6.1)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C76Je-0005YK-3t
for eap-archive@ietf.org; Tue, 14 Sep 2004 01:57:23 -0400
To: eap-archive@ietf.org
Subject: Fwd: our offer
Date: Tue, 14 Sep 2004 03:47:16 -0300
From: "Marci Arevalo"
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 22.5 (++++++++++++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: quoted-printable
Glasses were used with feverish activity!!=20
Looking for not expensive high-quality software?
We might have just what you need.
Windows XP Profess=
ional 2002 ............. $50
Adobe Photoshop 7=
0 ...................... $60
Microsoft Office X=
P Professional 2002 .... $60
Corel Draw Graphics=
Suite 11 ............. $60
and lots more... =
a>
TOP quality software:
Special Offer #1:
Windows XP Profe=
ssional+Microsoft Office XP Professional
=3D only $80
Special Offer #2:
Adobe - Photoshop =
7, Premiere 7, Illustrator 10 =3D only
$120
Special Offer #3:
Macromedia Dream=
waver MX 2004 + Flash MX 2004 =3D only $100
Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage
Enter Here=
?q9svYHquR.xPIqqqZB">Discontinue
The monster emerged some fathoms from the water, and then threw out that v=
ery intense but mysterious light mentioned in the report of several captai=
ns? But if there should remain two or more who have equal votes, the Senat=
e shall choose from them by ballot the Vice President. Taking into conside=
ration the mean of observations made at divers times -- rejecting the timi=
d estimate of those who assigned to this object a length of two hundred fe=
et, equally with the exaggerated opinions which set it down as a mile in w=
idth and three in length -- we might fairly conclude that this mysterious =
being surpassed greatly all dimensions admitted by the learned ones of the=
day, if it existed at all.=20
From zdwxdmi@att.net Tue Sep 14 15:29:46 2004
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 PAA07711;
Tue, 14 Sep 2004 15:29:46 -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 1C7J4p-0005Dy-E5; Tue, 14 Sep 2004 15:34:55 -0400
Received: from [221.2.75.4] (helo=65.246.255.50)
by mx2.foretec.com with smtp (Exim 4.24)
id 1C7Izq-0007eS-7r; Tue, 14 Sep 2004 15:29:46 -0400
X-Message-Info: WxqxPWP215zuKBJ616ZyprNDC378GZNagKI3K794DAY5sqp90BDH
Received: (from f7commissariat@localhost)
by ha5-extractor124.d2pq.mcimail.com (1.20.25/1.38.05) id ogv1L19mlo474837;
Tue, 14 Sep 2004 17:27:09 -0300 GMT
X-Authentication-Warning: x86-rabbet6.ys5n.mcimail.com: z14stephen set sender to zdwxdmi@att.net using -i
MIME-Version: 1.0
Date: Tue, 14 Sep 2004 15:30:09 -0500
From: Protection agains HIV viruses
Subject: Miracle protein to help you
To: eap-archive@ietf.org
Message-Id:
Content-Type: multipart/alternative;
boundary="--410618252101243"
X-Spam-Score: 11.8 (+++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
----410618252101243
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
'THE ANTIDOTE'
Kills ALL known deadly Viruses & Bacteria in the body that keep diseases, =
namely: Influenza, SARS, Cancer, HIV etc.
A disease must be made DORMANT to stop infection.
'The ANTIDOTE' is the answer.
www.biowonder.biz/hp/
Free shipping & 30-day money back guarantee
WE ARE THE ONLY COMPANY IN THE WORLD WHO HAVE DEVELOPED AND ENHANCED THIS =
PRODUCT FOR SALE.
Check Here For More Information
www.biowonder.biz/hp/
Not Interested?
http://get-it-online.info/soft/chair.php
-----------
brooklyn tenant downtrodden counterclockwise satisfaction fixture daffodil=
stymie mongolia derriere marco atheism epidemic belfry elaine bisexual di=
alysis munson acid concrete strop contributory seriatim polytope callaghan=
nagging libreville ninety synopses who've engage brunswick intestate conv=
ulsive incomprehensible paprika birdwatch alway built suntanned amok tap t=
hrice taiwan arrangeable lisa offload porcine transferral blur crania draf=
t evil cochineal clever scud bury trichrome sampson hem teaspoon expelling=
maggot coachman horace chorine ankle corinth acclamation blab wear wield =
porch lean chuckle emissary fit bookkeep privet angola endemic alterate ab=
dicate haiti collude degenerate traceable burgeon bigelow primordial libid=
inous cataclysm graves cudgel atlantic grotesque crease syllabi graduate k=
ava preach bergstrom protophyta defrock stack chorale candidacy bravery bl=
onde nightshirt chariot kiddie product clear perseus triptych curran chef =
tepid drugging descriptive anatomic ejector prerequisite protect begotten =
fractious comprehend kaiser harness distort peasanthood dictate powerful d=
irt hanford troll voss addressograph abut saddlebag sisyphus concur antipe=
rspirant abroad backscatter incomplete exportation kraft nostradamus cumin=
kamchatka withal couple interfere cowpunch aau accomplish bitch counterpo=
int catatonic cushing cyprus wraith sketchy tanaka obsolescent bowen clima=
x gil fibration arabia angus apperception science valuate privilege brett =
fourth molybdenum coiffure anorthic who zeroth oilmen workmen daughter pea=
sant church frictional eagan pall can receptacle seance fluoresce cutler p=
ortmanteau sunburn pyrotechnic assyriology shutdown densitometer judas cel=
anese float twofold oregano adolescent n bedim entry passenger dibble appa=
rition twofold tour scab nuisance cheesecake caprice horizontal cringe dro=
wsy decimal md camaraderie bucknell clare coachwork oblivion niche ecole a=
sperity trig estop sextillion alumni moody triennial repellent protrude ho=
tbed laue douce bock obvious fortiori baird cane icebox bunk diphtheria an=
nounce einstein medal combine alma neophyte tenebrous hazy cornmeal burrow=
beget berlitz typify horseshoe warehouseman biddy sims crosby eigenspace =
tiresome jibe danubian park angelfish whistleable durance upstate yore baw=
d birthright
----410618252101243--
From curd.239326gruesome@bbs-la.com Tue Sep 14 17:57:00 2004
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 RAA26112;
Tue, 14 Sep 2004 17:57:00 -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 1C7LNK-0002Lt-MY; Tue, 14 Sep 2004 18:02:12 -0400
Received: from [222.99.44.199] (helo=65.246.255.50)
by mx2.foretec.com with smtp (Exim 4.24)
id 1C7LIF-0003dP-1p; Tue, 14 Sep 2004 17:56:55 -0400
Received: from middlemen2iberialax (80.83.851.22) by mail95.livecapital.com (emittulane LGRNQ 4.1.247)
id 45533QB4IWC8053MV32793 for iab-wireless-workshop@ietf.org; Wed, 15 Sep 2004 01:51:12 +0300
X-MIME-Autoconverted: Yes
Disclose-Recipients: No
Discarded-X400-MTS-Extensions: Yes
Alternate-Recipient: Allowed
X-No-Archive: Yes
Reply-To: "Bryon Nash"
From: "Bryon Nash"
To: iab-wireless-workshop@ietf.org
Cc: seamoby@ietf.org, bpana@ietf.org, owner-ietf-outbound@ietf.org,
entmib-request@ietf.org, xmldsig-archive@ietf.org,
rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org,
r-wg-admin@ietf.org
Subject: FW: M[o]rtgage Application
Date: Tue, 14 Sep 2004 19:54:12 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--7242688377591471647"
Message-Id:
X-Spam-Score: 7.3 (+++++++)
X-Spam-Flag: YES
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
----7242688377591471647
Content-Type: text/html;
charset="iso-7220-4"
Content-Transfer-Encoding: 7Bit
Dear Applicant,
Your application was processed and approved. You are eligible for a 2.3% rate and a $400,000 loan.
Please verify your information here:
http://centrex.ondemandloan.info/s6/ke.php?jq1=55
We look forward to hearing from you.
Regards,
Bryon Nash
Senior Account Manager
Webber Financial Association
----7242688377591471647--
From eap-admin@frascone.com Tue Sep 14 23:38:08 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23470
for ; Tue, 14 Sep 2004 23:38:08 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 8B53F1FD6C; Tue, 14 Sep 2004 23:38:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id E07DD2211C; Tue, 14 Sep 2004 23:38:02 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 522E72211C
for ; Tue, 14 Sep 2004 23:37:04 -0400 (EDT)
Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110])
by mail.frascone.com (Postfix) with ESMTP id 82A421FD6C
for ; Tue, 14 Sep 2004 23:37:02 -0400 (EDT)
Received: from jm by jm.kir.nu with local (Exim 4.41)
id 1C7QZh-0002CV-KC; Tue, 14 Sep 2004 20:35:17 -0700
From: Jouni Malinen
To: henry.haverinen@nokia.com, jsalowey@cisco.com, jari.arkko@ericsson.com
Cc: eap@frascone.com
Message-ID: <20040915033517.GB7360@jm.kir.nu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] EAP-SIM/AKA identity selection after counter-too-small
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Tue, 14 Sep 2004 20:35:17 -0700
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
(draft 12) and have been trying to complete full interop tests for
more or less all features in the drafts with an authentication
server. Successful authentication cases seem to work fine: full
authentication with both permanent id and change to pseudonym works
and so does fast reauthentication. Many of the error cases, both
client error and notifications, are also interoperating. However,
testing AT_COUNTER_TOO_SMALL has had some problems, both due to
implementation bugs and mismatches in interpretation of the draft.
Bugs are now mostly fixed, but since there were mismatches in
interpretation, it might be useful to consider extending the example
of fast reauthentication when counter is not fresh (figure 9 of
EAP-SIM draft 13) to include the full authentication part with
explicitly mentioning the used identities for each message and the
identity used in MK derivation.
While going through the details of how the identity is selected for MK
derivation I noticed a potential issue with the drafts. I'm covering
EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in
practice, identical construction for fast-reauth and consequently, the
same problem is present (just replace SIM with AKA and subtype Start
with Identity in the description).
Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
possible sources for Identity that is used as data for SHA1(). It can
be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start
or from the identity included in the previous EAP-Response/Identity.
However, there is one case in which neither of these is available,
namely, counter-not-fresh case when EAP-Request/Identity is not used.
How should the identity in MK derivation be selected for this case?
The example message sequences below show more details. The first case
is with EAP-Request/Identity and this can be completed based on the
draft description. Using reauth_id in MK derivation, i.e., in fullauth
case, is potentially confusing, but that seems to be the way to go
when following the current draft (it is the identity from previous
EAP-Response/Identity since previous EAP-Response/SIM/Start did not
include AT_IDENTITY).
The second case is from situation where EAP-Request/Identity is not
used at all. Authentication starts with EAP-Request/SIM/Start with
AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start.
However, counter-not-fresh case (chapter 4.3.5) specifies that server
MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start
and consequently, following EAP-Response/SIM/Start does not include
AT_IDENTITY. This will trigger the case where it is not clear which
identity would be used in MK derivation.
With EAP-Request/Identity:
A: EAP-Request/Identity
P: EAP-Response/Identity (1|IMSI = permanent id)
A: EAP-Request/SIM/Start (AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
*AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
(use 1|IMSI as the Identity in MK derivation)
P: EAP-Response/SIM/Challenge (AT_MAC)
A: EAP-Success
A: EAP-Request/Identity
P: EAP-Response/Identity (20000@example.com = reauth_id from prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
*AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER,
*AT_PADDING, AT_MAC)
A: EAP-Success
A: EAP-Request/Identity
P: EAP-Response/Identity (20001@example.com = reauth_id from prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
*AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
A: EAP-Request/SIM/Start (AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
*AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
(use 20001@example.com as the Identity in MK derivation, i.e.,
AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not
AT_NEXT_REAUTH_ID of the reauth attempt with too small counter)
P: EAP-Response/SIM/Challenge (AT_MAC)
A: EAP-Success
Without EAP-Request/Identity:
A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
AT_SELECTED_VERSION)
(identity = 1|IMSI = permanent id)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
*AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
(use 1|IMSI as the Identity in MK derivation)
P: EAP-Response/SIM/Challenge (AT_MAC)
A: EAP-Success
A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
AT_SELECTED_VERSION)
(identity = 20000@example.com = reauth_id from prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
*AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER,
*AT_PADDING, AT_MAC)
A: EAP-Success
A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
AT_SELECTED_VERSION)
(identity = 20001@example.com = reauth_id from prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
*AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
A: EAP-Request/SIM/Start (AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
*AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
Which Identity should be used in MK derivation now? Previous
EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already
learned identity from the failed reauth attempt) and
EAP-Response/Identity was not used. Chapter 4.6 Key Generation
mentions these two options for Identity, but neither one is available
here.. Should this be specified to use reauth_id from the AT_IDENTITY
of the previous SIM/Start or permanent id (which should always be
known by both AS and Peer at this point) or something else?
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From lywvgwyvsfnuh@yahoo.com Wed Sep 15 03:27:41 2004
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 DAA07299;
Wed, 15 Sep 2004 03:27:41 -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 1C7UHg-0004kj-Ox; Wed, 15 Sep 2004 03:32:58 -0400
Received: from [61.182.248.183] (helo=65.246.255.50)
by mx2.foretec.com with smtp (Exim 4.24)
id 1C7UCW-0000jk-C4; Wed, 15 Sep 2004 03:27:38 -0400
Received: from 138.161.192.133 by 61.182.248.183; Wed, 15 Sep 2004 10:31:49 +0200
Message-ID:
From: "Tamra Mullen"
Reply-To: "Tamra Mullen"
To: bpana@ietf.org
Subject: Attn: Infected: Spyware Alert
Date: Wed, 15 Sep 2004 02:31:49 -0600
X-Mailer: AOL 9.0 for Windows US sub 272
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--535608914494788"
X-Priority: 1
X-MSMail-Priority: High
X-IP: 196.158.96.4
X-Spam-Score: 36.3 (++++++++++++++++++++++++++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
----535608914494788
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable
Auto Detect!Spyware Loaded,Clean it Now!
----535608914494788--
From eap-admin@frascone.com Wed Sep 15 06:12:06 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18840
for ; Wed, 15 Sep 2004 06:12:05 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 211C020D0D; Wed, 15 Sep 2004 06:12:07 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 9C6A921547; Wed, 15 Sep 2004 06:12:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 286DA20C82
for ; Wed, 15 Sep 2004 06:11:33 -0400 (EDT)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
by mail.frascone.com (Postfix) with ESMTP id DCBC62001A
for ; Wed, 15 Sep 2004 06:11:30 -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 i8FABRT09881;
Wed, 15 Sep 2004 13:11:27 +0300 (EET DST)
X-Scanned: Wed, 15 Sep 2004 13:08:10 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i8FA8APc025461;
Wed, 15 Sep 2004 13:08:10 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
by esdks004.ntc.nokia.com 00zxNeXQ; Wed, 15 Sep 2004 13:07:11 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 i8FA70Y05172;
Wed, 15 Sep 2004 13:07:00 +0300 (EET DST)
Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
Wed, 15 Sep 2004 13:06:55 +0300
Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
Wed, 15 Sep 2004 13:06:55 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID:
Thread-Topic: EAP-SIM/AKA identity selection after counter-too-small
Thread-Index: AcSa1X/o8ADqTEGgTIWQmeXCmc78AgAIZJJg
From:
To: , ,
Cc:
X-OriginalArrivalTime: 15 Sep 2004 10:06:55.0296 (UTC) FILETIME=[BABAB400:01C49B0B]
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] RE: EAP-SIM/AKA identity selection after counter-too-small
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Wed, 15 Sep 2004 13:06:40 +0300
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: quoted-printable
Jouni,
Many thanks for your detailed analysis! I'm glad to hear
your interoperability testing is going so well.=20
I agree that the problem you pointed out exists; the drafts
are not clear on what identity to use in MK derivation
when the preceding EAP-Response/SIM/Start does not include
AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
in an earlier EAP-Response/SIM/Start.
You already listed the two most natural resolutions:
1) The AT_IDENTITY from the previous EAP-Response/SIM/Start
2) permanent identity, although it was not used in any
identity string during the authentication exchange.
In my opinion, number 1) would be more in line with the
"spirit" of the draft -- the purpose is to protect=20
the last identity string communicated in the protocol. So I think we=20
should change section 6.4. (Key Generation) as follows:
..
Identity denotes the peer identity string without any terminating
null characters. It is the identity from the last AT_IDENTITY =
attribute
sent by the peer in this EAP exchange, or, if AT_IDENTITY was not =
used=20
during the EAP exchange, the identity from the EAP-Response/Identity =
packet.=20
The identity string is included as-is, without any changes.=20
We should also include an example message sequence of this=20
AT_COUNTER_TOO_SMALL case.
Any opinions?
BR,
Henry
> -----Original Message-----
> From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext=20
> Jouni Malinen
> Sent: 15 September, 2004 06:35
> To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
> jari.arkko@ericsson.com
> Cc: eap@frascone.com
> Subject: EAP-SIM/AKA identity selection after counter-too-small
>=20
>=20
> I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
> (draft 12) and have been trying to complete full interop tests for
> more or less all features in the drafts with an authentication
> server. Successful authentication cases seem to work fine: full
> authentication with both permanent id and change to pseudonym works
> and so does fast reauthentication. Many of the error cases, both
> client error and notifications, are also interoperating. However,
> testing AT_COUNTER_TOO_SMALL has had some problems, both due to
> implementation bugs and mismatches in interpretation of the draft.
>=20
> Bugs are now mostly fixed, but since there were mismatches in
> interpretation, it might be useful to consider extending the example
> of fast reauthentication when counter is not fresh (figure 9 of
> EAP-SIM draft 13) to include the full authentication part with
> explicitly mentioning the used identities for each message and the
> identity used in MK derivation.
>=20
> While going through the details of how the identity is selected for MK
> derivation I noticed a potential issue with the drafts. I'm covering
> EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in
> practice, identical construction for fast-reauth and consequently, the
> same problem is present (just replace SIM with AKA and subtype Start
> with Identity in the description).
>=20
> Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
> possible sources for Identity that is used as data for SHA1(). It can
> be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start
> or from the identity included in the previous EAP-Response/Identity.
> However, there is one case in which neither of these is available,
> namely, counter-not-fresh case when EAP-Request/Identity is not used.
> How should the identity in MK derivation be selected for this case?
>=20
> The example message sequences below show more details. The first case
> is with EAP-Request/Identity and this can be completed based on the
> draft description. Using reauth_id in MK derivation, i.e., in fullauth
> case, is potentially confusing, but that seems to be the way to go
> when following the current draft (it is the identity from previous
> EAP-Response/Identity since previous EAP-Response/SIM/Start did not
> include AT_IDENTITY).
>=20
> The second case is from situation where EAP-Request/Identity is not
> used at all. Authentication starts with EAP-Request/SIM/Start with
> AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start.
> However, counter-not-fresh case (chapter 4.3.5) specifies that server
> MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start
> and consequently, following EAP-Response/SIM/Start does not include
> AT_IDENTITY. This will trigger the case where it is not clear which
> identity would be used in MK derivation.
>=20
>=20
> With EAP-Request/Identity:
>=20
> A: EAP-Request/Identity
> P: EAP-Response/Identity (1|IMSI =3D permanent id)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
> (use 1|IMSI as the Identity in MK derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>=20
>=20
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20000@example.com =3D reauth_id from=20
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,=20
> *AT_COUNTER,
> *AT_PADDING, AT_MAC)
> A: EAP-Success
>=20
>=20
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20001@example.com =3D reauth_id from=20
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
> (use 20001@example.com as the Identity in MK derivation, i.e.,
> AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not
> AT_NEXT_REAUTH_ID of the reauth attempt with too small counter)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>=20
>=20
>=20
> Without EAP-Request/Identity:
>=20
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity =3D 1|IMSI =3D permanent id)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
> (use 1|IMSI as the Identity in MK derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>=20
>=20
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity =3D 20000@example.com =3D reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,=20
> *AT_COUNTER,
> *AT_PADDING, AT_MAC)
> A: EAP-Success
>=20
>=20
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity =3D 20001@example.com =3D reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>=20
> Which Identity should be used in MK derivation now? Previous
> EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already
> learned identity from the failed reauth attempt) and
> EAP-Response/Identity was not used. Chapter 4.6 Key Generation
> mentions these two options for Identity, but neither one is available
> here.. Should this be specified to use reauth_id from the AT_IDENTITY
> of the previous SIM/Start or permanent id (which should always be
> known by both AS and Peer at this point) or something else?
>=20
>=20
> --=20
> Jouni Malinen PGP=20
> id EFC895FA
>=20
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From bbzvxy@alltel.net Wed Sep 15 20:58:51 2004
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 UAA29766;
Wed, 15 Sep 2004 20:58:51 -0400 (EDT)
Received: from adsl-68-78-244-220.dsl.sbndin.ameritech.net ([68.78.244.220])
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C7kh4-0001lW-5d; Wed, 15 Sep 2004 21:04:17 -0400
X-Message-Info: 131sEsC3GPgsK6QA862HODdflLehxiGdwaYTing3BDC
Received: from webtv.net (50.24.220.241) by jzt4-oc1.webtv.net with Microsoft SMTPSVC(9.2.2064.6538);
Thu, 16 Sep 2004 06:02:05 +0400
Received: from webtv.net (webtv.net 34.72.194.4)
by webtv.net (8.12.10/8.12.9) with ESMTP id h081OCEQSC127
for ; Wed, 15 Sep 2004 21:53:05 -0400 (EST)
(envelope-from bbzvxy@alltel.net)
Received: from RKG21640093665 (modemcable7.3-08.ihd.webtv.net 162.186.144.48)
(authenticated bits=1)
by webtv.net (8.12.10/8.12.9) with ESMTP id dbx979Q7n276
for ; Wed, 15 Sep 2004 21:54:05 -0400 (EST)
(envelope-from bbzvxy@alltel.net)
Message-ID: <064o377ncy07$i07r2u8$450wdd36v201@I40754292286265>
From: "Rolex At $99."
To:
Subject: Do not settle for less than a ROLEX.-Eap-archive dishevel wastewater
Date: Thu, 16 Sep 2004 00:54:05 -0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--8245470518191924303"
X-Spam-Score: 2.5 (++)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
----8245470518191924303
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Italian Rolex
--------------from $99 !!
also available :
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CARTIER
FRANK MULLER
Jager-LeCoultre
OMEGA
PATEK PHILIPE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
AND MORE
http://itsmyreplica.info/index.php?ref=3Dhp=20
Italian Crafted Rolex - Complete Watch Store
Reliable Service and Support
Check Here For More Information
http://itsmyreplica.info/index.php?ref=3Dhp=20
Regards
Joan Kemp
-----------
sidle legume reactionary nomograph intersperse locomote hospice haven't em=
ission ccny diety spikenard gemstone corroborate beribbon wagoneer guanidi=
ne furniture benny halpern coachman covetous bumblebee dirichlet hostelry =
gaston diagnose ellipsoid cryogenic metalloid shipwreck cool hygiene media=
n spaghetti enunciate venetian laundry margery mud dragging sarasota audit=
ory chuckle turbine swollen tube seminal lustful pitilessly adultery basic=
muon facetious schist cabinetry zodiac pip grandeur filial satanic cicada=
meg adsorption wheelchair hide furrow manumit central cacti rheumatic nut=
shell babbitt transference peremptory rivet armada combine asset contiguit=
y bastion barfly heterogamous inveigle coffeepot hen crumb thong hertz bug=
aboo ouvre derail gaunt tag yerkes windowsill diathermy champaign catatoni=
c digestive cowbird coffee auction berkowitz college isis courtier annotat=
e perfect mclaughlin doreen dimension muncie kingfisher argo diphtheria mi=
dshipmen conquer chopin electrophoresis chantilly podium meadow consistent=
emerson silverman anodic tuberculin analytic elaborate darlene squibb art=
hur decryption rowland buenos smyrna gorgon puma bellum cryptanalyst impis=
h fixture nebula ready cavort novelty mantis gesticulate azerbaijan bison =
crag drink aphorism graphic compline cowbell quizzes cohosh acts mid defau=
lt dastard adsorption gluey cabinetmake agrarian oven demise breach sympos=
ia dehydrate winnetka breathtaking allusion antecedent compulsive charitab=
le vaporous ascomycetes rococo siva vintner resistant bismarck veda citrus=
datum testamentary kelp carlin acton shoemake psychology constructible in=
terceptor mcconnell breezy idea rotary marmot corrigendum cahill octavia l=
ettuce antarctica typesetter astound cacophonist petersen exchange lars fl=
eet assassin braggart belvedere chickadee coven inexplicit rook ask amnesi=
a giuseppe conversant spigot knoweth bluish machinelike around actinolite =
drafty nasturtium wesleyan pirogue janice typesetting officialdom doughnut=
teakettle stratford breadth philodendron rudder hera tremor petri adoptiv=
e buckwheat perseverance congresswoman affirmation perplex atmosphere ampl=
y dicotyledon norma marianne stallion leash ancillary delilah stoichiometr=
y moist communicable cladophora yogurt citric barth pupil feudal axle ervi=
n capsule telethon worthington clown wacky cossack austria becalm collard =
atalanta amarillo
----8245470518191924303--
From eap-admin@frascone.com Thu Sep 16 06:00:11 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27690
for ; Thu, 16 Sep 2004 06:00:11 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 1E787222D6; Thu, 16 Sep 2004 06:00:10 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 5248F222D8; Thu, 16 Sep 2004 06:00:05 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id E50D3222D8
for ; Thu, 16 Sep 2004 05:59:06 -0400 (EDT)
Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
by mail.frascone.com (Postfix) with ESMTP id 4E327222D6
for ; Thu, 16 Sep 2004 05:59:04 -0400 (EDT)
Received: from intoto (2mc66.intotoind.com [172.16.2.66])
by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i8G9wv78027260
for ; Thu, 16 Sep 2004 15:28:57 +0530
From: "Suresh"
To:
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <20040915033517.GB7360@jm.kir.nu>
Importance: Normal
X-Scanned-By: MIMEDefang 2.41
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] Retransmission in EAP-Relay
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Thu, 16 Sep 2004 15:29:30 +0530
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
Hi,
I have a query regarding retransmission in RFC-3579.
The setup.
EAP-Client (RFC-3579)--------- RADIUS Server
| |
Lower layer x -------------------- Lower layer x
Assume that lower layer supports retransmission and RADIUS server sent
an Access-Challenge packet with EAP packet and also set session timeout
attribute.
1) Should the retransmission time interval of the Lower layer
be over rided with the Access-Challenge session timeout attribute value
for that EAP-packet?
OR
2) Should Authenticator ignore the value of Access-challenge session timeout
attribute and leave the retransmission functionality to the Lower layer?
Thanks
-Suresh
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From peppery_bury672519@tds.net Thu Sep 16 20:34:50 2004
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 UAA03934;
Thu, 16 Sep 2004 20:34:50 -0400 (EDT)
Message-Id: <200409170034.UAA03934@ietf.org>
Received: from [61.110.212.218] (helo=132.151.6.1)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C86nZ-0000ya-75; Thu, 16 Sep 2004 20:40:29 -0400
Received: from peppery_bury672519@tds.net (40.96.24.128)
by xite748.sa.61.110.212.218 with QMQP; Fri, 17 Sep 2004 03:31:46 +0300
X-MIME-Autoconverted: Yes
Alternate-Recipient: Allowed
Auto-Forwarded: Yes
Xref: machejhemjpxphsntjok
Reply-To: "Gerald Whaley"
From: "Gerald Whaley"
To: rpsec-request@ietf.org
Cc: ietf-outbound.07@ietf.org, ran@ietf.org, r-wg-admin@ietf.org,
seamoby@ietf.org, rpr@ietf.org, er-wgchairs@ietf.org,
eap-archive@ietf.org
Subject: Guess What? Good News!
Date: Fri, 17 Sep 2004 06:36:46 +0600
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--712195983677806"
X-Spam-Score: 13.8 (+++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
----712195983677806
Content-Type: text/html;
charset="iso-5113-4"
Content-Transfer-Encoding: 7Bit
Dear Applicant,
We received your application and we're happy to let you know that it
has been approved. You now qualify for a $425,000 loan at 2.8%.
Please verify your information here:
http://www.bargainloan.info/q2/li.php?jq1=63
We look forward to hearing from you.
Regards,
Gerald Whaley
Account Manager
not interested
----712195983677806--
From LillianReffitt@erols.com Thu Sep 16 23:41:22 2004
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 XAA15724
for ; Thu, 16 Sep 2004 23:41:22 -0400 (EDT)
Message-Id: <200409170341.XAA15724@ietf.org>
Received: from cdm-66-76-251-152.tyrd.cox-internet.com ([66.76.251.152])
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C89i9-000522-3k
for eap-archive@ietf.org; Thu, 16 Sep 2004 23:47:04 -0400
To: eap-archive@ietf.org
Subject: hey
Date: Fri, 17 Sep 2004 06:36:08 +0200
From: "Flynn Foshie"
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: quoted-printable
The interior arrangements of the frigate corresponded to =
its nautical qualities.=20
discontinue
He raised his head sometimes, looked before us, and uttered a cry of recog=
nition, which was responded to by a voice that came nearer and nearer. Mer=
chants, common sailors, captains of vessels, skippers, both of Europe and =
America, naval officers of all countries, and the Governments of several S=
tates on the two continents, were deeply interested in the matter. In all =
the other cases before mentioned, the Supreme Court shall have appellate j=
urisdiction, both as to law and fact, with such exceptions, and under such=
regulations as the Congress shall make; The trial of all crimes, except i=
n cases of impeachment, shall be by jury; and such trial shall be held in =
the state where the said crimes shall have been committed; but when not co=
mmitted within any state, the trial shall be at such place or places as th=
e Congress may by law have directed!!=20
From DominiqueOltmanns@free4life.us Fri Sep 17 08:08:26 2004
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 IAA28815
for ; Fri, 17 Sep 2004 08:08:26 -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 1C8Hcv-00084L-00
for eap-archive@ietf.org; Fri, 17 Sep 2004 08:14:10 -0400
Received: from 103.221-200-80.adsl.skynet.be ([80.200.221.103])
by mx2.foretec.com with smtp (Exim 4.24)
id 1C8HXI-0004pI-PS
for eap-archive@ietf.org; Fri, 17 Sep 2004 08:08:22 -0400
From: "Faith Rhines"
To: eap-archive@ietf.org
Subject: I need your help...
Date: Fri, 17 Sep 2004 14:06:21 +0100
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id:
X-Spam-Score: 4.5 (++++)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: quoted-printable
Each House may determine the rules of its proceedings, pu=
nish its members for disorderly behavior, and, with the concurrence of two=
thirds, expel a member
no msg
The Congress shall have power to declare the punishment of treason, but no=
attainder of treason shall work corruption of blood, or forfeiture except=
during the life of the person attainted? Fortunately this compartment did=
not hold the boilers, or the fires would have been immediately extinguish=
ed:=20
From wzpqubwfpv@ix.netcom.com Sat Sep 18 12:02:33 2004
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 MAA28130;
Sat, 18 Sep 2004 12:02:28 -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 1C8hkg-0003M6-2J; Sat, 18 Sep 2004 12:08:29 -0400
Received: from [211.44.116.114] (helo=65.246.255.50)
by mx2.foretec.com with smtp (Exim 4.24)
id 1C8heo-0002l1-Mj; Sat, 18 Sep 2004 12:01:52 -0400
X-Message-Info: OAUihFUR956iiqXBzdcNb7Ddwt49+YDNSpby9qVU
Received: from rqeohdccc0.bigfoot.com (86.240.232.128) by gzy31-i46.bigfoot.com with Microsoft SMTPSVC(5.0.2195.6824);
Sat, 18 Sep 2004 15:58:21 -0100
Received: from Alejandronzu094y03s9d (78.184.60.164) by cyzjnvrfbfdiz67.bigfoot.com
(InterMail vM.5.01.06.05 843-678-219-167-821-476456510) with SMTP
id <31845631197065.IOO84.mlmmmyi73070.bigfoot.com@ostracodm000rkh51l6kkc>
for ; Sat, 18 Sep 2004 09:56:21 -0700
Message-ID: <8916lt46te720$095845$y3twj87@Alejandrod964g37x06bz>
From: "Do you like Rolex."
To:
Subject: Even you can afford a Rolex now.Come on In !!-Ietf-archive cb 23 nn
Date: Sat, 18 Sep 2004 10:05:21 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--0175244179858539402"
X-Spam-Score: 3.3 (+++)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
----0175244179858539402
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Hello,
We all want to wear SWISS WATCHS,
they are expensive-we all know that,
Now we have effordable Replica's--
Rolex
--------------from $99 !!
also available :
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CARTIER
FRANK MULLER
Jager-LeCoultre
OMEGA
PATEK PHILIPE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
AND MORE
http://watchescanafford.info/index.php?ref=3Dhp
Italian Crafted Rolex - Complete Watch Store
Reliable Service and Support
Check Here For More Information
http://watchescanafford.info/index.php?ref=3Dhp
Regards
Alejandro Cantu
-----------
typewritten delineament simplicial pirouette pica datsun esprit scala bric=
k mound chicano grove dagger audacious guideline feat evocation aerial mut=
ant windbag finny optimum draftsman minima parrish beograd checklist great=
coat juliet fortuitous stockholm halogen declaratory hazelnut afflict frag=
ment posner scallop io tangential biplane ami bloodline shotbush jansenist=
cerulean virtual colombo adjacent greenhouse collinear scour antonym bech=
tel remission brookhaven mincemeat stirling supernatant wilshire topsy mil=
dew heigh bilabial inductor dogtrot winkle epileptic simplify puckish inde=
composable lenient media destiny clutch bedridden rasmussen tubule ferocit=
y genii lob natchez corridor mayst thenceforth deplore demijohn plankton p=
ong gauze decomposition ovenbird soviet often brazen gassy chambers mortal=
bombproof aboveground ttl age lila dread drowsy acetic potentiometer oval=
urgent terminology gangland sticktight quince tilt alight cottage hug irr=
esolution armenian mercurial uterus analogy testamentary downright venture=
apprehend argonne confucius clay trigonal cemetery restroom commandant ch=
ecksumming eddie mine tompkins drophead banter curricula always seduce kid=
napping emulate ameliorate prefix minor maladaptive keep musk togging rule=
lorraine aerogene picayune conjugal perfidy daimler catalyst injury titan=
ium texas documentation erwin doubloon effectuate bootlegging chord catapu=
lt cyanic civic delicious dramatic systemization cartography kirov woodcut=
brunhilde nonchalant louisa welfare prom wi tuskegee rustic baudelaire fi=
fth magdalene conflagration manama nil picket dun privacy glottal ruff apo=
thegm bent authoritarian hateful ardent tailgate delouse remunerate metall=
urgist applause ripoff pup yiddish hearken creekside cutover fruition biom=
etrika marks barberry mila plagioclase furthermost rig ursuline angeline v=
incent attributive declamatory reformatory care filamentary constance curd=
le sheehan dirichlet avoid mitten distinct councilwoman politicking chroni=
c admitted fiction drama gleam dwindle epic cachalot block crimp fontaineb=
leau bam harmful muddle goddess closeup regretful clarity pandora earthmov=
ing bronzy veery econometrica crockery conversion thebes debutante micron =
resist schedule humid advert ising karamazov habitat billie stefan bewilde=
r troop coccidiosis valery cyclopean anthology big trustworthy mercuric
----0175244179858539402--
From YRKIGYBNBSZTY@hush.com Sat Sep 18 13:09:09 2004
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 NAA01515;
Sat, 18 Sep 2004 13:09: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 1C8inH-0004Zz-GY; Sat, 18 Sep 2004 13:15:04 -0400
Received: from yahoobb220041088004.bbtec.net ([220.41.88.4])
by mx2.foretec.com with smtp (Exim 4.24)
id 1C8ihL-0005oZ-JT; Sat, 18 Sep 2004 13:08:32 -0400
Received: from 184.88.216.170 by 220.41.88.4; Sat, 18 Sep 2004 22:08:28 +0400
Message-ID:
From: "Claudette Tomlinson"
Reply-To: "Claudette Tomlinson"
To: rmt-request@ietf.org
Subject: S.ave up to 80% online meds
Date: Sat, 18 Sep 2004 16:01:28 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--853446277701021211"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
----853446277701021211
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Stop wasting money on prescription drugs. Get them online for 80=
% off.
V1agra, C1alis, Xanax, Val1um, Xen1cal, And many many more...Sto=
p paying more than you have too! and start saving today!
Click on the f=
ollowing link
http://www.onlinecheapmeds.com/?refid=3D16
MsgID: 033-139
----853446277701021211--
From eap-admin@frascone.com Sat Sep 18 17:25:44 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17037
for ; Sat, 18 Sep 2004 17:25:43 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 4FB6C2035C; Sat, 18 Sep 2004 17:25:11 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id DB2CE20A32; Sat, 18 Sep 2004 17:25:05 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id DD75020970
for ; Sat, 18 Sep 2004 17:23:29 -0400 (EDT)
Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
by mail.frascone.com (Postfix) with ESMTP id C3F77205C9
for ; Sat, 18 Sep 2004 17:23:21 -0400 (EDT)
Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62])
by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8HClIXx003699;
Fri, 17 Sep 2004 18:17:18 +0530
Message-Id: <5.1.0.14.0.20040917180017.02ace940@172.16.1.10>
X-Sender: umas@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: henry.haverinen@nokia.com, jkmaline@cc.hut.fi, jsalowey@cisco.com,
jari.arkko@ericsson.com
From: Uma Shankar Ch
Subject: RE: [eap] RE: EAP-SIM/AKA identity selection after
counter-too-small
Cc: eap@frascone.com
In-Reply-To:
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_22264379==_.ALT"
X-Scanned-By: MIMEDefang 2.41
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Fri, 17 Sep 2004 18:18:07 +0530
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
--=====================_22264379==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Henry,
Excuse me, you are absolutely correct. For the Figure 9 above, where EAP
exchange started with EAP-Request/Identity, one must use the
EAP-Response/Identity only in MK calculation for the specified case in
4.3.5. In that sense, the statement completely holds good.
For this case
A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
AT_SELECTED_VERSION)
(identity = 20001@example.com = reauth_id from prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
*AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
A: EAP-Request/SIM/Start (AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
*AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
as pointed by Jouni, according to the new change introduced by you, both
'A' and 'P' would be using the identity from the last AT_IDENTITY (ie.,
20001@example.com --- in this case) for MK calculation.
For this case, this example exchange would be really useful to understand
things quickly in the draft.
Thanks for correcting my understanding.
--Uma
At 02:11 PM 9/17/04 +0300, henry.haverinen@nokia.com wrote:
>
>Hi Uma,
>
>I'm not sure I understand why the last sentence (you bolded) would
>become invalid. When the counter is too small, the peer should still
>discard the new re-authentication identity which is received in the same
>message
>as the too small a counter, even with the proposed change. That is, the
>peer should discard
>the identity the server included in AT_NEXT_REAUTH_ID of the
>EAP-Request/SIM/Re-authentication message that has too small a counter
>value in AT_COUNTER.
>
>I think this is still valid, even when the EAP exchange consists of a
>counter-too-small
>re-authentication and a full authentication. In this case, when
>EAP-Response/Identity
>is not used, the peer and the server use the peer identity sent by the
>peer to the server in
>the first EAP-Response/SIM/Start.
>
>Maybe we should clarify section 4.3.5 so that it is clear which
>AT_NEXT_REAUTH_ID
>needs to be discarded?
>
>Best regards,
>Henry
>-----Original Message-----
>From: ext Uma Shankar Ch [mailto:umas@intotoinc.com]
>Sent: 17 September, 2004 07:28
>To: Haverinen Henry (Nokia-ES/Jyvaskyla); jkmaline@cc.hut.fi;
>jsalowey@cisco.com; jari.arkko@ericsson.com
>Cc: eap@frascone.com
>Subject: Re: [eap] RE: EAP-SIM/AKA identity selection after counter-too-small
>
>>Hi Henry,
>>
>>Just to mention --
>>
>>With the proposed change, you may would like to remove the text as it
>>would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure
>>when Counter is Too Small) -- the last sentence in paragraph
>>
>> "When the peer detects that the
>> counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
>> attribute in EAP-Response/SIM/Re-authentication. This attribute
>> doesn't contain any data but it is a request for the server to
>> initiate full authentication. In this case, the peer MUST ignore the
>> contents of the server's AT_NEXT_REAUTH_ID attribute."
>>
>>--Uma
>>
>>
>>
>>At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote:
>>
>>>Jouni,
>>>
>>>Many thanks for your detailed analysis! I'm glad to hear
>>>your interoperability testing is going so well.
>>>
>>>I agree that the problem you pointed out exists; the drafts
>>>are not clear on what identity to use in MK derivation
>>>when the preceding EAP-Response/SIM/Start does not include
>>>AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
>>>in an earlier EAP-Response/SIM/Start.
>>>
>>>You already listed the two most natural resolutions:
>>>
>>>1) The AT_IDENTITY from the previous EAP-Response/SIM/Start
>>>
>>>2) permanent identity, although it was not used in any
>>>identity string during the authentication exchange.
>>>
>>>In my opinion, number 1) would be more in line with the
>>>"spirit" of the draft -- the purpose is to protect
>>>the last identity string communicated in the protocol. So I think we
>>>should change section 6.4. (Key Generation) as follows:
>>>
>>> ..
>>> Identity denotes the peer identity string without any terminating
>>> null characters. It is the identity from the last AT_IDENTITY attribute
>>> sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used
>>> during the EAP exchange, the identity from the EAP-Response/Identity
>>> packet.
>>> The identity string is included as-is, without any changes.
>>>We should also include an example message sequence of this
>>>AT_COUNTER_TOO_SMALL case.
>>>
>>>Any opinions?
>>>
>>>BR,
>>>Henry
>>>
>>>
>>>
>>> > -----Original Message-----
>>> > From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext
>>> > Jouni Malinen
>>> > Sent: 15 September, 2004 06:35
>>> > To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
>>> > jari.arkko@ericsson.com
>>> > Cc: eap@frascone.com
>>> > Subject: EAP-SIM/AKA identity selection after counter-too-small
>>> >
>>> >
>>> > I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
>>> > (draft 12) and have been trying to complete full interop tests for
>>> > more or less all features in the drafts with an authentication
>>> > server. Successful authentication cases seem to work fine: full
>>> > authentication with both permanent id and change to pseudonym works
>>> > and so does fast reauthentication. Many of the error cases, both
>>> > client error and notifications, are also interoperating. However,
>>> > testing AT_COUNTER_TOO_SMALL has had some problems, both due to
>>> > implementation bugs and mismatches in interpretation of the draft.
>>> >
>>> > Bugs are now mostly fixed, but since there were mismatches in
>>> > interpretation, it might be useful to consider extending the example
>>> > of fast reauthentication when counter is not fresh (figure 9 of
>>> > EAP-SIM draft 13) to include the full authentication part with
>>> > explicitly mentioning the used identities for each message and the
>>> > identity used in MK derivation.
>>> >
>>> > While going through the details of how the identity is selected for MK
>>> > derivation I noticed a potential issue with the drafts. I'm covering
>>> > EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in
>>> > practice, identical construction for fast-reauth and consequently, the
>>> > same problem is present (just replace SIM with AKA and subtype Start
>>> > with Identity in the description).
>>> >
>>> > Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
>>> > possible sources for Identity that is used as data for SHA1(). It can
>>> > be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start
>>> > or from the identity included in the previous EAP-Response/Identity.
>>> > However, there is one case in which neither of these is available,
>>> > namely, counter-not-fresh case when EAP-Request/Identity is not used.
>>> > How should the identity in MK derivation be selected for this case?
>>> >
>>> > The example message sequences below show more details. The first case
>>> > is with EAP-Request/Identity and this can be completed based on the
>>> > draft description. Using reauth_id in MK derivation, i.e., in fullauth
>>> > case, is potentially confusing, but that seems to be the way to go
>>> > when following the current draft (it is the identity from previous
>>> > EAP-Response/Identity since previous EAP-Response/SIM/Start did not
>>> > include AT_IDENTITY).
>>> >
>>> > The second case is from situation where EAP-Request/Identity is not
>>> > used at all. Authentication starts with EAP-Request/SIM/Start with
>>> > AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start.
>>> > However, counter-not-fresh case (chapter 4.3.5) specifies that server
>>> > MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start
>>> > and consequently, following EAP-Response/SIM/Start does not include
>>> > AT_IDENTITY. This will trigger the case where it is not clear which
>>> > identity would be used in MK derivation.
>>> >
>>> >
>>> > With EAP-Request/Identity:
>>> >
>>> > A: EAP-Request/Identity
>>> > P: EAP-Response/Identity (1|IMSI = permanent id)
>>> > A: EAP-Request/SIM/Start (AT_VERSION_LIST)
>>> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
>>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>>> > (use 1|IMSI as the Identity in MK derivation)
>>> > P: EAP-Response/SIM/Challenge (AT_MAC)
>>> > A: EAP-Success
>>> >
>>> >
>>> > A: EAP-Request/Identity
>>> > P: EAP-Response/Identity (20000@example.com = reauth_id from
>>> > prev auth)
>>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>>> > *AT_NONCE_S, AT_MAC)
>>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>>> > *AT_COUNTER,
>>> > *AT_PADDING, AT_MAC)
>>> > A: EAP-Success
>>> >
>>> >
>>> > A: EAP-Request/Identity
>>> > P: EAP-Response/Identity (20001@example.com = reauth_id from
>>> > prev auth)
>>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>>> > *AT_NONCE_S, AT_MAC)
>>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>>> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
>>> > A: EAP-Request/SIM/Start (AT_VERSION_LIST)
>>> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
>>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>>> > (use 20001@example.com as the Identity in MK derivation, i.e.,
>>> > AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not
>>> > AT_NEXT_REAUTH_ID of the reauth attempt with too small counter)
>>> > P: EAP-Response/SIM/Challenge (AT_MAC)
>>> > A: EAP-Success
>>> >
>>> >
>>> >
>>> > Without EAP-Request/Identity:
>>> >
>>> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
>>> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
>>> > AT_SELECTED_VERSION)
>>> > (identity = 1|IMSI = permanent id)
>>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>>> > (use 1|IMSI as the Identity in MK derivation)
>>> > P: EAP-Response/SIM/Challenge (AT_MAC)
>>> > A: EAP-Success
>>> >
>>> >
>>> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
>>> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
>>> > AT_SELECTED_VERSION)
>>> > (identity = 20000@example.com = reauth_id from prev auth)
>>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>>> > *AT_NONCE_S, AT_MAC)
>>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>>> > *AT_COUNTER,
>>> > *AT_PADDING, AT_MAC)
>>> > A: EAP-Success
>>> >
>>> >
>>> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
>>> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
>>> > AT_SELECTED_VERSION)
>>> > (identity = 20001@example.com = reauth_id from prev auth)
>>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>>> > *AT_NONCE_S, AT_MAC)
>>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>>> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
>>> > A: EAP-Request/SIM/Start (AT_VERSION_LIST)
>>> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
>>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>>> >
>>> > Which Identity should be used in MK derivation now? Previous
>>> > EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already
>>> > learned identity from the failed reauth attempt) and
>>> > EAP-Response/Identity was not used. Chapter 4.6 Key Generation
>>> > mentions these two options for Identity, but neither one is available
>>> > here.. Should this be specified to use reauth_id from the AT_IDENTITY
>>> > of the previous SIM/Start or permanent id (which should always be
>>> > known by both AS and Peer at this point) or something else?
>>> >
>>> >
>>> > --
>>> > Jouni Malinen PGP
>>> > id EFC895FA
>>> >
>>>_______________________________________________
>>>eap mailing list
>>>eap@frascone.com
>>>http://mail.frascone.com/mailman/listinfo/eap
--=====================_22264379==_.ALT
Content-Type: text/html; charset="us-ascii"
Hi Henry,
Excuse me, you are absolutely correct. For the Figure 9 above, where EAP
exchange started with EAP-Request/Identity, one must use the
EAP-Response/Identity only in MK calculation for the specified case in
4.3.5. In that sense, the statement completely holds good.
For this case
A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
AT_SELECTED_VERSION)
(identity = 20001@example.com = reauth_id from
prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID,
*AT_PADDING,
*AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
*AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING,
AT_MAC)
A: EAP-Request/SIM/Start (AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
*AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
as pointed by Jouni, according to the new change introduced by you, both
'A' and 'P' would be using the identity from the last AT_IDENTITY (ie.,
20001@example.com --- in this case) for MK calculation.
For this case, this example exchange would be really useful to understand
things quickly in the draft.
Thanks for correcting my understanding.
--Uma
At 02:11 PM 9/17/04 +0300, henry.haverinen@nokia.com wrote:
Hi Uma,
I'm not sure I understand why
the last sentence (you bolded) would
become invalid. When the
counter is too small, the peer should still
discard the new
re-authentication identity which is received in the same
message
as the too small a counter,
even with the proposed change. That is, the peer should
discard
the identity the server
included in AT_NEXT_REAUTH_ID of the
EAP-Request/SIM/Re-authentication
message that has too small a counter
value in AT_COUNTER.
I think this is still valid,
even when the EAP exchange consists of a counter-too-small
re-authentication and a full
authentication. In this case, when EAP-Response/Identity
is not used, the peer and the
server use the peer identity sent by the peer to the server
in
the first
EAP-Response/SIM/Start.
Maybe we should clarify section
4.3.5 so that it is clear which AT_NEXT_REAUTH_ID
needs to be
discarded?
Best regards,
Henry
- -----Original Message-----
- From:
ext Uma Shankar Ch
[mailto:umas@intotoinc.com]
Sent: 17 September, 2004 07:28
To: Haverinen Henry (Nokia-ES/Jyvaskyla); jkmaline@cc.hut.fi;
jsalowey@cisco.com; jari.arkko@ericsson.com
Cc: eap@frascone.com
Subject: Re: [eap] RE: EAP-SIM/AKA identity selection after
counter-too-small
Hi Henry,
Just to mention --
With the proposed change, you may would like to remove the text as it
would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure
when Counter is Too Small) -- the last sentence in paragraph
"When the peer detects that the
counter value is not fresh, it includes the
AT_COUNTER_TOO_SMALL
attribute in EAP-Response/SIM/Re-authentication. This
attribute
doesn't contain any data but it is a request for the
server to
initiate full authentication. In this case, the peer
MUST ignore the
contents of the server's AT_NEXT_REAUTH_ID
attribute."
--Uma
At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote:
Jouni,
Many thanks for your detailed analysis! I'm glad to hear
your interoperability testing is going so well.
I agree that the problem you pointed out exists; the drafts
are not clear on what identity to use in MK derivation
when the preceding EAP-Response/SIM/Start does not include
AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
in an earlier EAP-Response/SIM/Start.
You already listed the two most natural resolutions:
1) The AT_IDENTITY from the previous EAP-Response/SIM/Start
2) permanent identity, although it was not used in any
identity string during the authentication exchange.
In my opinion, number 1) would be more in line with the
"spirit" of the draft -- the purpose is to protect
the last identity string communicated in the protocol. So I think we
should change section 6.4. (Key Generation) as follows:
..
Identity denotes the peer identity string without any
terminating
null characters. It is the identity from the last
AT_IDENTITY attribute
sent by the peer in this EAP exchange, or, if
AT_IDENTITY was not used
during the EAP exchange, the identity from the
EAP-Response/Identity packet.
The identity string is included as-is, without any
changes.
We should also include an example message sequence of this
AT_COUNTER_TOO_SMALL case.
Any opinions?
BR,
Henry
> -----Original Message-----
> From: Jouni Malinen
[mailto:jm@jm.kir.nu]On
Behalf Of ext
> Jouni Malinen
> Sent: 15 September, 2004 06:35
> To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
> jari.arkko@ericsson.com
> Cc: eap@frascone.com
> Subject: EAP-SIM/AKA identity selection after
counter-too-small
>
>
> I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
> (draft 12) and have been trying to complete full interop tests
for
> more or less all features in the drafts with an authentication
> server. Successful authentication cases seem to work fine:
full
> authentication with both permanent id and change to pseudonym
works
> and so does fast reauthentication. Many of the error cases,
both
> client error and notifications, are also interoperating.
However,
> testing AT_COUNTER_TOO_SMALL has had some problems, both due
to
> implementation bugs and mismatches in interpretation of the
draft.
>
> Bugs are now mostly fixed, but since there were mismatches in
> interpretation, it might be useful to consider extending the
example
> of fast reauthentication when counter is not fresh (figure 9
of
> EAP-SIM draft 13) to include the full authentication part with
> explicitly mentioning the used identities for each message and
the
> identity used in MK derivation.
>
> While going through the details of how the identity is selected
for MK
> derivation I noticed a potential issue with the drafts. I'm
covering
> EAP-SIM case here, but it looks like EAP-AKA (draft 12) has,
in
> practice, identical construction for fast-reauth and
consequently, the
> same problem is present (just replace SIM with AKA and subtype
Start
> with Identity in the description).
>
> Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
> possible sources for Identity that is used as data for SHA1().
It can
> be either from the AT_IDENTITY of the previous
EAP-Response/SIM/Start
> or from the identity included in the previous
EAP-Response/Identity.
> However, there is one case in which neither of these is
available,
> namely, counter-not-fresh case when EAP-Request/Identity is not
used.
> How should the identity in MK derivation be selected for this
case?
>
> The example message sequences below show more details. The first
case
> is with EAP-Request/Identity and this can be completed based on
the
> draft description. Using reauth_id in MK derivation, i.e., in
fullauth
> case, is potentially confusing, but that seems to be the way to
go
> when following the current draft (it is the identity from
previous
> EAP-Response/Identity since previous EAP-Response/SIM/Start did
not
> include AT_IDENTITY).
>
> The second case is from situation where EAP-Request/Identity is
not
> used at all. Authentication starts with EAP-Request/SIM/Start
with
> AT_ANY_ID_REQ, followed by AT_IDENTITY in
EAP-Response/SIM/Start.
> However, counter-not-fresh case (chapter 4.3.5) specifies that
server
> MUST NOT include any of the ID_REQ attributes in
EAP-Request/SIM/Start
> and consequently, following EAP-Response/SIM/Start does not
include
> AT_IDENTITY. This will trigger the case where it is not clear
which
> identity would be used in MK derivation.
>
>
> With EAP-Request/Identity:
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (1|IMSI = permanent id)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
> (use 1|IMSI as the Identity in MK
derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20000@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
> *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20001@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER_TOO_SMALL, *AT_COUNTER,
*AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
> (use 20001@example.com as the Identity in MK
derivation, i.e.,
> AT_NEXT_REAUTH_ID from the last successful
fullauth/reauth, not
> AT_NEXT_REAUTH_ID of the reauth attempt with
too small counter)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
>
> Without EAP-Request/Identity:
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity = 1|IMSI = permanent id)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
> (use 1|IMSI as the Identity in MK
derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity = 20000@example.com =
reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
> *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity = 20001@example.com =
reauth_id from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER_TOO_SMALL, *AT_COUNTER,
*AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
>
> Which Identity should be used in MK derivation now? Previous
> EAP-Response/SIM/Start did not have AT_IDENTITY (since AS
already
> learned identity from the failed reauth attempt) and
> EAP-Response/Identity was not used. Chapter 4.6 Key Generation
> mentions these two options for Identity, but neither one is
available
> here.. Should this be specified to use reauth_id from the
AT_IDENTITY
> of the previous SIM/Start or permanent id (which should always
be
> known by both AS and Peer at this point) or something else?
>
>
> --
> Jouni
Malinen
PGP
> id EFC895FA
>
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
--=====================_22264379==_.ALT--
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Sat Sep 18 17:29:23 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17198
for ; Sat, 18 Sep 2004 17:29:22 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id EC0E921195; Sat, 18 Sep 2004 17:27:07 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id BDE74211C5; Sat, 18 Sep 2004 17:27:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id ECF3C205C9
for ; Sat, 18 Sep 2004 17:23:32 -0400 (EDT)
Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
by mail.frascone.com (Postfix) with ESMTP id 1F4DB2067C
for ; Sat, 18 Sep 2004 17:23:29 -0400 (EDT)
Received: from intoto (2mc66.intotoind.com [172.16.2.66])
by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i8H6lL9u007653;
Fri, 17 Sep 2004 12:17:21 +0530
From: "Suresh"
To: "Srinivasa Rao Addepalli" ,
Subject: RE: [eap] Retransmission in EAP-Relay
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <002901c49c22$9f0df650$6f05010a@SriniSony>
Importance: High
X-Scanned-By: MIMEDefang 2.41
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Fri, 17 Sep 2004 12:17:54 +0530
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
But the RFC-3579 section 2.3 Retransmission says
It may be necessary to adjust retransmission strategies and
authentication timeouts in certain cases. For example, when a token
card is used additional time may be required to allow the user to
find the card and enter the token. Since the NAS will typically not
have knowledge of the required parameters, these need to be provided
by the RADIUS server. This can be accomplished by inclusion of
Session-Timeout attribute within the Access-Challenge packet.
-----Original Message-----
From: Srinivasa Rao Addepalli [mailto:srao@intoto.com]
Sent: Friday, September 17, 2004 12:53 AM
To: Suresh; eap@frascone.com
Subject: Re: [eap] Retransmission in EAP-Relay
I suggest option 2. I don't think session timeout is meant for this anyway.
Srini
Intoto Inc.
www.intoto.com
----- Original Message -----
From: "Suresh"
To:
Sent: Thursday, September 16, 2004 2:59 AM
Subject: [eap] Retransmission in EAP-Relay
> Hi,
> I have a query regarding retransmission in RFC-3579.
>
>
> The setup.
>
> EAP-Client (RFC-3579)--------- RADIUS Server
> | |
> Lower layer x -------------------- Lower layer x
>
> Assume that lower layer supports retransmission and RADIUS server sent
> an Access-Challenge packet with EAP packet and also set session timeout
> attribute.
>
> 1) Should the retransmission time interval of the Lower layer
> be over rided with the Access-Challenge session timeout attribute value
> for that EAP-packet?
>
> OR
>
> 2) Should Authenticator ignore the value of Access-challenge session
timeout
> attribute and leave the retransmission functionality to the Lower layer?
>
>
> Thanks
> -Suresh
>
>
> _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Sat Sep 18 17:32:39 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17323
for ; Sat, 18 Sep 2004 17:32:38 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 956D620BCC; Sat, 18 Sep 2004 17:28:08 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 9BCBA2056C; Sat, 18 Sep 2004 17:28:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 4003D207FC
for ; Sat, 18 Sep 2004 17:23:38 -0400 (EDT)
Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
by mail.frascone.com (Postfix) with ESMTP id 830DC20538
for ; Sat, 18 Sep 2004 17:23:32 -0400 (EDT)
Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62])
by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8H4RHY3012736;
Fri, 17 Sep 2004 09:57:17 +0530
Message-Id: <5.1.0.14.0.20040917095649.02ac6020@172.16.1.10>
X-Sender: umas@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: henry.haverinen@nokia.com, jkmaline@cc.hut.fi, jsalowey@cisco.com,
jari.arkko@ericsson.com
From: Uma Shankar Ch
Subject: Re: [eap] RE: EAP-SIM/AKA identity selection after
counter-too-small
Cc: eap@frascone.com
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_56406744==_.ALT"
X-Scanned-By: MIMEDefang 2.41
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Fri, 17 Sep 2004 09:58:03 +0530
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
--=====================_56406744==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
>Hi Henry,
>
>Just to mention --
>
>With the proposed change, you may would like to remove the text as it
>would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure
>when Counter is Too Small) -- the last sentence in paragraph
>
> "When the peer detects that the
> counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
> attribute in EAP-Response/SIM/Re-authentication. This attribute
> doesn't contain any data but it is a request for the server to
> initiate full authentication. In this case, the peer MUST ignore the
> contents of the server's AT_NEXT_REAUTH_ID attribute."
>
>--Uma
>
>
>At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote:
>
>>Jouni,
>>
>>Many thanks for your detailed analysis! I'm glad to hear
>>your interoperability testing is going so well.
>>
>>I agree that the problem you pointed out exists; the drafts
>>are not clear on what identity to use in MK derivation
>>when the preceding EAP-Response/SIM/Start does not include
>>AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
>>in an earlier EAP-Response/SIM/Start.
>>
>>You already listed the two most natural resolutions:
>>
>>1) The AT_IDENTITY from the previous EAP-Response/SIM/Start
>>
>>2) permanent identity, although it was not used in any
>>identity string during the authentication exchange.
>>
>>In my opinion, number 1) would be more in line with the
>>"spirit" of the draft -- the purpose is to protect
>>the last identity string communicated in the protocol. So I think we
>>should change section 6.4. (Key Generation) as follows:
>>
>> ..
>> Identity denotes the peer identity string without any terminating
>> null characters. It is the identity from the last AT_IDENTITY attribute
>> sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used
>> during the EAP exchange, the identity from the EAP-Response/Identity
>> packet.
>> The identity string is included as-is, without any changes.
>>
>>We should also include an example message sequence of this
>>AT_COUNTER_TOO_SMALL case.
>>
>>Any opinions?
>>
>>BR,
>>Henry
>>
>>
>> > -----Original Message-----
>> > From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext
>> > Jouni Malinen
>> > Sent: 15 September, 2004 06:35
>> > To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
>> > jari.arkko@ericsson.com
>> > Cc: eap@frascone.com
>> > Subject: EAP-SIM/AKA identity selection after counter-too-small
>> >
>> >
>> > I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
>> > (draft 12) and have been trying to complete full interop tests for
>> > more or less all features in the drafts with an authentication
>> > server. Successful authentication cases seem to work fine: full
>> > authentication with both permanent id and change to pseudonym works
>> > and so does fast reauthentication. Many of the error cases, both
>> > client error and notifications, are also interoperating. However,
>> > testing AT_COUNTER_TOO_SMALL has had some problems, both due to
>> > implementation bugs and mismatches in interpretation of the draft.
>> >
>> > Bugs are now mostly fixed, but since there were mismatches in
>> > interpretation, it might be useful to consider extending the example
>> > of fast reauthentication when counter is not fresh (figure 9 of
>> > EAP-SIM draft 13) to include the full authentication part with
>> > explicitly mentioning the used identities for each message and the
>> > identity used in MK derivation.
>> >
>> > While going through the details of how the identity is selected for MK
>> > derivation I noticed a potential issue with the drafts. I'm covering
>> > EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in
>> > practice, identical construction for fast-reauth and consequently, the
>> > same problem is present (just replace SIM with AKA and subtype Start
>> > with Identity in the description).
>> >
>> > Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
>> > possible sources for Identity that is used as data for SHA1(). It can
>> > be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start
>> > or from the identity included in the previous EAP-Response/Identity.
>> > However, there is one case in which neither of these is available,
>> > namely, counter-not-fresh case when EAP-Request/Identity is not used.
>> > How should the identity in MK derivation be selected for this case?
>> >
>> > The example message sequences below show more details. The first case
>> > is with EAP-Request/Identity and this can be completed based on the
>> > draft description. Using reauth_id in MK derivation, i.e., in fullauth
>> > case, is potentially confusing, but that seems to be the way to go
>> > when following the current draft (it is the identity from previous
>> > EAP-Response/Identity since previous EAP-Response/SIM/Start did not
>> > include AT_IDENTITY).
>> >
>> > The second case is from situation where EAP-Request/Identity is not
>> > used at all. Authentication starts with EAP-Request/SIM/Start with
>> > AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start.
>> > However, counter-not-fresh case (chapter 4.3.5) specifies that server
>> > MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start
>> > and consequently, following EAP-Response/SIM/Start does not include
>> > AT_IDENTITY. This will trigger the case where it is not clear which
>> > identity would be used in MK derivation.
>> >
>> >
>> > With EAP-Request/Identity:
>> >
>> > A: EAP-Request/Identity
>> > P: EAP-Response/Identity (1|IMSI = permanent id)
>> > A: EAP-Request/SIM/Start (AT_VERSION_LIST)
>> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>> > (use 1|IMSI as the Identity in MK derivation)
>> > P: EAP-Response/SIM/Challenge (AT_MAC)
>> > A: EAP-Success
>> >
>> >
>> > A: EAP-Request/Identity
>> > P: EAP-Response/Identity (20000@example.com = reauth_id from
>> > prev auth)
>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>> > *AT_NONCE_S, AT_MAC)
>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>> > *AT_COUNTER,
>> > *AT_PADDING, AT_MAC)
>> > A: EAP-Success
>> >
>> >
>> > A: EAP-Request/Identity
>> > P: EAP-Response/Identity (20001@example.com = reauth_id from
>> > prev auth)
>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>> > *AT_NONCE_S, AT_MAC)
>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
>> > A: EAP-Request/SIM/Start (AT_VERSION_LIST)
>> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>> > (use 20001@example.com as the Identity in MK derivation, i.e.,
>> > AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not
>> > AT_NEXT_REAUTH_ID of the reauth attempt with too small counter)
>> > P: EAP-Response/SIM/Challenge (AT_MAC)
>> > A: EAP-Success
>> >
>> >
>> >
>> > Without EAP-Request/Identity:
>> >
>> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
>> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
>> > AT_SELECTED_VERSION)
>> > (identity = 1|IMSI = permanent id)
>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>> > (use 1|IMSI as the Identity in MK derivation)
>> > P: EAP-Response/SIM/Challenge (AT_MAC)
>> > A: EAP-Success
>> >
>> >
>> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
>> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
>> > AT_SELECTED_VERSION)
>> > (identity = 20000@example.com = reauth_id from prev auth)
>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>> > *AT_NONCE_S, AT_MAC)
>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>> > *AT_COUNTER,
>> > *AT_PADDING, AT_MAC)
>> > A: EAP-Success
>> >
>> >
>> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
>> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
>> > AT_SELECTED_VERSION)
>> > (identity = 20001@example.com = reauth_id from prev auth)
>> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
>> > *AT_NONCE_S, AT_MAC)
>> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
>> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
>> > A: EAP-Request/SIM/Start (AT_VERSION_LIST)
>> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
>> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
>> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
>> >
>> > Which Identity should be used in MK derivation now? Previous
>> > EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already
>> > learned identity from the failed reauth attempt) and
>> > EAP-Response/Identity was not used. Chapter 4.6 Key Generation
>> > mentions these two options for Identity, but neither one is available
>> > here.. Should this be specified to use reauth_id from the AT_IDENTITY
>> > of the previous SIM/Start or permanent id (which should always be
>> > known by both AS and Peer at this point) or something else?
>> >
>> >
>> > --
>> > Jouni Malinen PGP
>> > id EFC895FA
>> >
>>_______________________________________________
>>eap mailing list
>>eap@frascone.com
>>http://mail.frascone.com/mailman/listinfo/eap
--=====================_56406744==_.ALT
Content-Type: text/html; charset="us-ascii"
Hi Henry,
Just to mention --
With the proposed change, you may would like to remove the text as it
would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure
when Counter is Too Small) -- the last sentence in paragraph
"When the peer detects that the
counter value is not fresh, it includes the
AT_COUNTER_TOO_SMALL
attribute in EAP-Response/SIM/Re-authentication. This
attribute
doesn't contain any data but it is a request for the server
to
initiate full authentication. In this case, the peer MUST
ignore the
contents of the server's AT_NEXT_REAUTH_ID
attribute."
--Uma
At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote:
Jouni,
Many thanks for your detailed analysis! I'm glad to hear
your interoperability testing is going so well.
I agree that the problem you pointed out exists; the drafts
are not clear on what identity to use in MK derivation
when the preceding EAP-Response/SIM/Start does not include
AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
in an earlier EAP-Response/SIM/Start.
You already listed the two most natural resolutions:
1) The AT_IDENTITY from the previous EAP-Response/SIM/Start
2) permanent identity, although it was not used in any
identity string during the authentication exchange.
In my opinion, number 1) would be more in line with the
"spirit" of the draft -- the purpose is to protect
the last identity string communicated in the protocol. So I think we
should change section 6.4. (Key Generation) as follows:
..
Identity denotes the peer identity string without any
terminating
null characters. It is the identity from the last
AT_IDENTITY attribute
sent by the peer in this EAP exchange, or, if AT_IDENTITY
was not used
during the EAP exchange, the identity from the
EAP-Response/Identity packet.
The identity string is included as-is, without any changes.
We should also include an example message sequence of this
AT_COUNTER_TOO_SMALL case.
Any opinions?
BR,
Henry
> -----Original Message-----
> From: Jouni Malinen
[mailto:jm@jm.kir.nu]On
Behalf Of ext
> Jouni Malinen
> Sent: 15 September, 2004 06:35
> To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
> jari.arkko@ericsson.com
> Cc: eap@frascone.com
> Subject: EAP-SIM/AKA identity selection after
counter-too-small
>
>
> I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
> (draft 12) and have been trying to complete full interop tests
for
> more or less all features in the drafts with an authentication
> server. Successful authentication cases seem to work fine:
full
> authentication with both permanent id and change to pseudonym
works
> and so does fast reauthentication. Many of the error cases,
both
> client error and notifications, are also interoperating.
However,
> testing AT_COUNTER_TOO_SMALL has had some problems, both due
to
> implementation bugs and mismatches in interpretation of the
draft.
>
> Bugs are now mostly fixed, but since there were mismatches in
> interpretation, it might be useful to consider extending the
example
> of fast reauthentication when counter is not fresh (figure 9
of
> EAP-SIM draft 13) to include the full authentication part with
> explicitly mentioning the used identities for each message and
the
> identity used in MK derivation.
>
> While going through the details of how the identity is selected for
MK
> derivation I noticed a potential issue with the drafts. I'm
covering
> EAP-SIM case here, but it looks like EAP-AKA (draft 12) has,
in
> practice, identical construction for fast-reauth and consequently,
the
> same problem is present (just replace SIM with AKA and subtype
Start
> with Identity in the description).
>
> Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
> possible sources for Identity that is used as data for SHA1(). It
can
> be either from the AT_IDENTITY of the previous
EAP-Response/SIM/Start
> or from the identity included in the previous
EAP-Response/Identity.
> However, there is one case in which neither of these is
available,
> namely, counter-not-fresh case when EAP-Request/Identity is not
used.
> How should the identity in MK derivation be selected for this
case?
>
> The example message sequences below show more details. The first
case
> is with EAP-Request/Identity and this can be completed based on
the
> draft description. Using reauth_id in MK derivation, i.e., in
fullauth
> case, is potentially confusing, but that seems to be the way to
go
> when following the current draft (it is the identity from
previous
> EAP-Response/Identity since previous EAP-Response/SIM/Start did
not
> include AT_IDENTITY).
>
> The second case is from situation where EAP-Request/Identity is
not
> used at all. Authentication starts with EAP-Request/SIM/Start
with
> AT_ANY_ID_REQ, followed by AT_IDENTITY in
EAP-Response/SIM/Start.
> However, counter-not-fresh case (chapter 4.3.5) specifies that
server
> MUST NOT include any of the ID_REQ attributes in
EAP-Request/SIM/Start
> and consequently, following EAP-Response/SIM/Start does not
include
> AT_IDENTITY. This will trigger the case where it is not clear
which
> identity would be used in MK derivation.
>
>
> With EAP-Request/Identity:
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (1|IMSI = permanent id)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
> (use 1|IMSI as the Identity in MK
derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20000@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
> *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20001@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER_TOO_SMALL, *AT_COUNTER,
*AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
> (use 20001@example.com as the Identity in MK
derivation, i.e.,
> AT_NEXT_REAUTH_ID from the last successful
fullauth/reauth, not
> AT_NEXT_REAUTH_ID of the reauth attempt with too
small counter)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
>
> Without EAP-Request/Identity:
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity = 1|IMSI = permanent id)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
> (use 1|IMSI as the Identity in MK
derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity = 20000@example.com = reauth_id
from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
> *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity = 20001@example.com = reauth_id
from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER_TOO_SMALL, *AT_COUNTER,
*AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
>
> Which Identity should be used in MK derivation now? Previous
> EAP-Response/SIM/Start did not have AT_IDENTITY (since AS
already
> learned identity from the failed reauth attempt) and
> EAP-Response/Identity was not used. Chapter 4.6 Key Generation
> mentions these two options for Identity, but neither one is
available
> here.. Should this be specified to use reauth_id from the
AT_IDENTITY
> of the previous SIM/Start or permanent id (which should always
be
> known by both AS and Peer at this point) or something else?
>
>
> --
> Jouni
Malinen
PGP
> id EFC895FA
>
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
--=====================_56406744==_.ALT--
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Sat Sep 18 17:36:31 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17512
for ; Sat, 18 Sep 2004 17:36:30 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id BB87520FFD; Sat, 18 Sep 2004 17:30:07 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id CFC2020F47; Sat, 18 Sep 2004 17:30:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 2DC8D20A6C
for ; Sat, 18 Sep 2004 17:23:43 -0400 (EDT)
Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
by mail.frascone.com (Postfix) with ESMTP id D6915207BA
for ; Sat, 18 Sep 2004 17:23:37 -0400 (EDT)
Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62])
by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i8GEthcm009642;
Thu, 16 Sep 2004 20:25:43 +0530
Message-Id: <5.1.0.14.0.20040916202211.02ab6df0@172.16.1.10>
X-Sender: umas@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: , , ,
From: Uma Shankar Ch
Subject: Re: [eap] RE: EAP-SIM/AKA identity selection after
counter-too-small
Cc:
In-Reply-To:
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_7704504==_.ALT"
X-Scanned-By: MIMEDefang 2.41
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Thu, 16 Sep 2004 20:26:28 +0530
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
--=====================_7704504==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Henry,
Just to mention --
With the proposed change, you may would like to remove the text as it would
become invalid, in Section 4.3.5 (Fast Re-authentication Procedure when
Counter is Too Small) -- the last sentence in paragraph
"When the peer detects that the
counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
attribute in EAP-Response/SIM/Re-authentication. This attribute
doesn't contain any data but it is a request for the server to
initiate full authentication. In this case, the peer MUST ignore the
contents of the server's AT_NEXT_REAUTH_ID attribute."
--Uma
At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote:
>Jouni,
>
>Many thanks for your detailed analysis! I'm glad to hear
>your interoperability testing is going so well.
>
>I agree that the problem you pointed out exists; the drafts
>are not clear on what identity to use in MK derivation
>when the preceding EAP-Response/SIM/Start does not include
>AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
>in an earlier EAP-Response/SIM/Start.
>
>You already listed the two most natural resolutions:
>
>1) The AT_IDENTITY from the previous EAP-Response/SIM/Start
>
>2) permanent identity, although it was not used in any
>identity string during the authentication exchange.
>
>In my opinion, number 1) would be more in line with the
>"spirit" of the draft -- the purpose is to protect
>the last identity string communicated in the protocol. So I think we
>should change section 6.4. (Key Generation) as follows:
>
> ..
> Identity denotes the peer identity string without any terminating
> null characters. It is the identity from the last AT_IDENTITY attribute
> sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used
> during the EAP exchange, the identity from the EAP-Response/Identity
> packet.
> The identity string is included as-is, without any changes.
>
>We should also include an example message sequence of this
>AT_COUNTER_TOO_SMALL case.
>
>Any opinions?
>
>BR,
>Henry
>
>
> > -----Original Message-----
> > From: Jouni Malinen [mailto:jm@jm.kir.nu]On Behalf Of ext
> > Jouni Malinen
> > Sent: 15 September, 2004 06:35
> > To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
> > jari.arkko@ericsson.com
> > Cc: eap@frascone.com
> > Subject: EAP-SIM/AKA identity selection after counter-too-small
> >
> >
> > I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
> > (draft 12) and have been trying to complete full interop tests for
> > more or less all features in the drafts with an authentication
> > server. Successful authentication cases seem to work fine: full
> > authentication with both permanent id and change to pseudonym works
> > and so does fast reauthentication. Many of the error cases, both
> > client error and notifications, are also interoperating. However,
> > testing AT_COUNTER_TOO_SMALL has had some problems, both due to
> > implementation bugs and mismatches in interpretation of the draft.
> >
> > Bugs are now mostly fixed, but since there were mismatches in
> > interpretation, it might be useful to consider extending the example
> > of fast reauthentication when counter is not fresh (figure 9 of
> > EAP-SIM draft 13) to include the full authentication part with
> > explicitly mentioning the used identities for each message and the
> > identity used in MK derivation.
> >
> > While going through the details of how the identity is selected for MK
> > derivation I noticed a potential issue with the drafts. I'm covering
> > EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in
> > practice, identical construction for fast-reauth and consequently, the
> > same problem is present (just replace SIM with AKA and subtype Start
> > with Identity in the description).
> >
> > Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
> > possible sources for Identity that is used as data for SHA1(). It can
> > be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start
> > or from the identity included in the previous EAP-Response/Identity.
> > However, there is one case in which neither of these is available,
> > namely, counter-not-fresh case when EAP-Request/Identity is not used.
> > How should the identity in MK derivation be selected for this case?
> >
> > The example message sequences below show more details. The first case
> > is with EAP-Request/Identity and this can be completed based on the
> > draft description. Using reauth_id in MK derivation, i.e., in fullauth
> > case, is potentially confusing, but that seems to be the way to go
> > when following the current draft (it is the identity from previous
> > EAP-Response/Identity since previous EAP-Response/SIM/Start did not
> > include AT_IDENTITY).
> >
> > The second case is from situation where EAP-Request/Identity is not
> > used at all. Authentication starts with EAP-Request/SIM/Start with
> > AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start.
> > However, counter-not-fresh case (chapter 4.3.5) specifies that server
> > MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start
> > and consequently, following EAP-Response/SIM/Start does not include
> > AT_IDENTITY. This will trigger the case where it is not clear which
> > identity would be used in MK derivation.
> >
> >
> > With EAP-Request/Identity:
> >
> > A: EAP-Request/Identity
> > P: EAP-Response/Identity (1|IMSI = permanent id)
> > A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
> > (use 1|IMSI as the Identity in MK derivation)
> > P: EAP-Response/SIM/Challenge (AT_MAC)
> > A: EAP-Success
> >
> >
> > A: EAP-Request/Identity
> > P: EAP-Response/Identity (20000@example.com = reauth_id from
> > prev auth)
> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
> > *AT_NONCE_S, AT_MAC)
> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> > *AT_COUNTER,
> > *AT_PADDING, AT_MAC)
> > A: EAP-Success
> >
> >
> > A: EAP-Request/Identity
> > P: EAP-Response/Identity (20001@example.com = reauth_id from
> > prev auth)
> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
> > *AT_NONCE_S, AT_MAC)
> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> > A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
> > (use 20001@example.com as the Identity in MK derivation, i.e.,
> > AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not
> > AT_NEXT_REAUTH_ID of the reauth attempt with too small counter)
> > P: EAP-Response/SIM/Challenge (AT_MAC)
> > A: EAP-Success
> >
> >
> >
> > Without EAP-Request/Identity:
> >
> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> > AT_SELECTED_VERSION)
> > (identity = 1|IMSI = permanent id)
> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
> > (use 1|IMSI as the Identity in MK derivation)
> > P: EAP-Response/SIM/Challenge (AT_MAC)
> > A: EAP-Success
> >
> >
> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> > AT_SELECTED_VERSION)
> > (identity = 20000@example.com = reauth_id from prev auth)
> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
> > *AT_NONCE_S, AT_MAC)
> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> > *AT_COUNTER,
> > *AT_PADDING, AT_MAC)
> > A: EAP-Success
> >
> >
> > A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> > P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> > AT_SELECTED_VERSION)
> > (identity = 20001@example.com = reauth_id from prev auth)
> > A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> > *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
> > *AT_NONCE_S, AT_MAC)
> > P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> > *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
> > A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> > P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> > A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> > *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
> >
> > Which Identity should be used in MK derivation now? Previous
> > EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already
> > learned identity from the failed reauth attempt) and
> > EAP-Response/Identity was not used. Chapter 4.6 Key Generation
> > mentions these two options for Identity, but neither one is available
> > here.. Should this be specified to use reauth_id from the AT_IDENTITY
> > of the previous SIM/Start or permanent id (which should always be
> > known by both AS and Peer at this point) or something else?
> >
> >
> > --
> > Jouni Malinen PGP
> > id EFC895FA
> >
>_______________________________________________
>eap mailing list
>eap@frascone.com
>http://mail.frascone.com/mailman/listinfo/eap
--=====================_7704504==_.ALT
Content-Type: text/html; charset="us-ascii"
Hi Henry,
Just to mention --
With the proposed change, you may would like to remove the text as it
would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure
when Counter is Too Small) -- the last sentence in paragraph
"When the peer detects that the
counter value is not fresh, it includes the
AT_COUNTER_TOO_SMALL
attribute in EAP-Response/SIM/Re-authentication. This
attribute
doesn't contain any data but it is a request for the server
to
initiate full authentication. In this case, the peer MUST
ignore the
contents of the server's AT_NEXT_REAUTH_ID
attribute."
--Uma
At 01:06 PM 9/15/04 +0300, henry.haverinen@nokia.com wrote:
Jouni,
Many thanks for your detailed analysis! I'm glad to hear
your interoperability testing is going so well.
I agree that the problem you pointed out exists; the drafts
are not clear on what identity to use in MK derivation
when the preceding EAP-Response/SIM/Start does not include
AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
in an earlier EAP-Response/SIM/Start.
You already listed the two most natural resolutions:
1) The AT_IDENTITY from the previous EAP-Response/SIM/Start
2) permanent identity, although it was not used in any
identity string during the authentication exchange.
In my opinion, number 1) would be more in line with the
"spirit" of the draft -- the purpose is to protect
the last identity string communicated in the protocol. So I think we
should change section 6.4. (Key Generation) as follows:
..
Identity denotes the peer identity string without any
terminating
null characters. It is the identity from the last
AT_IDENTITY attribute
sent by the peer in this EAP exchange, or, if AT_IDENTITY
was not used
during the EAP exchange, the identity from the
EAP-Response/Identity packet.
The identity string is included as-is, without any changes.
We should also include an example message sequence of this
AT_COUNTER_TOO_SMALL case.
Any opinions?
BR,
Henry
> -----Original Message-----
> From: Jouni Malinen
[mailto:jm@jm.kir.nu]On
Behalf Of ext
> Jouni Malinen
> Sent: 15 September, 2004 06:35
> To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey@cisco.com;
> jari.arkko@ericsson.com
> Cc: eap@frascone.com
> Subject: EAP-SIM/AKA identity selection after
counter-too-small
>
>
> I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
> (draft 12) and have been trying to complete full interop tests
for
> more or less all features in the drafts with an authentication
> server. Successful authentication cases seem to work fine:
full
> authentication with both permanent id and change to pseudonym
works
> and so does fast reauthentication. Many of the error cases,
both
> client error and notifications, are also interoperating.
However,
> testing AT_COUNTER_TOO_SMALL has had some problems, both due
to
> implementation bugs and mismatches in interpretation of the
draft.
>
> Bugs are now mostly fixed, but since there were mismatches in
> interpretation, it might be useful to consider extending the
example
> of fast reauthentication when counter is not fresh (figure 9
of
> EAP-SIM draft 13) to include the full authentication part with
> explicitly mentioning the used identities for each message and
the
> identity used in MK derivation.
>
> While going through the details of how the identity is selected for
MK
> derivation I noticed a potential issue with the drafts. I'm
covering
> EAP-SIM case here, but it looks like EAP-AKA (draft 12) has,
in
> practice, identical construction for fast-reauth and consequently,
the
> same problem is present (just replace SIM with AKA and subtype
Start
> with Identity in the description).
>
> Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
> possible sources for Identity that is used as data for SHA1(). It
can
> be either from the AT_IDENTITY of the previous
EAP-Response/SIM/Start
> or from the identity included in the previous
EAP-Response/Identity.
> However, there is one case in which neither of these is
available,
> namely, counter-not-fresh case when EAP-Request/Identity is not
used.
> How should the identity in MK derivation be selected for this
case?
>
> The example message sequences below show more details. The first
case
> is with EAP-Request/Identity and this can be completed based on
the
> draft description. Using reauth_id in MK derivation, i.e., in
fullauth
> case, is potentially confusing, but that seems to be the way to
go
> when following the current draft (it is the identity from
previous
> EAP-Response/Identity since previous EAP-Response/SIM/Start did
not
> include AT_IDENTITY).
>
> The second case is from situation where EAP-Request/Identity is
not
> used at all. Authentication starts with EAP-Request/SIM/Start
with
> AT_ANY_ID_REQ, followed by AT_IDENTITY in
EAP-Response/SIM/Start.
> However, counter-not-fresh case (chapter 4.3.5) specifies that
server
> MUST NOT include any of the ID_REQ attributes in
EAP-Request/SIM/Start
> and consequently, following EAP-Response/SIM/Start does not
include
> AT_IDENTITY. This will trigger the case where it is not clear
which
> identity would be used in MK derivation.
>
>
> With EAP-Request/Identity:
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (1|IMSI = permanent id)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
> (use 1|IMSI as the Identity in MK
derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20000@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
> *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/Identity
> P: EAP-Response/Identity (20001@example.com = reauth_id from
> prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER_TOO_SMALL, *AT_COUNTER,
*AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
> (use 20001@example.com as the Identity in MK
derivation, i.e.,
> AT_NEXT_REAUTH_ID from the last successful
fullauth/reauth, not
> AT_NEXT_REAUTH_ID of the reauth attempt with too
small counter)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
>
> Without EAP-Request/Identity:
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity = 1|IMSI = permanent id)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
> (use 1|IMSI as the Identity in MK
derivation)
> P: EAP-Response/SIM/Challenge (AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity = 20000@example.com = reauth_id
from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER,
> *AT_PADDING, AT_MAC)
> A: EAP-Success
>
>
> A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
> AT_SELECTED_VERSION)
> (identity = 20001@example.com = reauth_id
from prev auth)
> A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER, *AT_NONCE_S,
*AT_NEXT_REAUTH_ID, *AT_PADDING,
> *AT_NONCE_S, AT_MAC)
> P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
> *AT_COUNTER_TOO_SMALL, *AT_COUNTER,
*AT_PADDING, AT_MAC)
> A: EAP-Request/SIM/Start (AT_VERSION_LIST)
> P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
> A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
> *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID,
*AT_PADDING, AT_MAC)
>
> Which Identity should be used in MK derivation now? Previous
> EAP-Response/SIM/Start did not have AT_IDENTITY (since AS
already
> learned identity from the failed reauth attempt) and
> EAP-Response/Identity was not used. Chapter 4.6 Key Generation
> mentions these two options for Identity, but neither one is
available
> here.. Should this be specified to use reauth_id from the
AT_IDENTITY
> of the previous SIM/Start or permanent id (which should always
be
> known by both AS and Peer at this point) or something else?
>
>
> --
> Jouni
Malinen
PGP
> id EFC895FA
>
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
--=====================_7704504==_.ALT--
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Sat Sep 18 18:16:05 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19913
for ; Sat, 18 Sep 2004 18:16:04 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 8026C201BD; Sat, 18 Sep 2004 18:16:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id F0C33200B9; Sat, 18 Sep 2004 18:16:02 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id E1FDA200B9
for ; Sat, 18 Sep 2004 18:15:59 -0400 (EDT)
Received: from intotoinc.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
by mail.frascone.com (Postfix) with ESMTP id EC475200AE
for ; Sat, 18 Sep 2004 18:15:57 -0400 (EDT)
Received: from SriniSony (dhcp-111.intoto.com [10.1.5.111])
by intotoinc.com (8.12.5/8.12.5) with SMTP id i8GJOE9D020972;
Thu, 16 Sep 2004 12:24:14 -0700
Message-ID: <002901c49c22$9f0df650$6f05010a@SriniSony>
From: "Srinivasa Rao Addepalli"
To: "Suresh" ,
References:
Subject: Re: [eap] Retransmission in EAP-Relay
Organization: Intoto Inc
MIME-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Thu, 16 Sep 2004 12:23:17 -0700
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
I suggest option 2. I don't think session timeout is meant for this anyway.
Srini
Intoto Inc.
www.intoto.com
----- Original Message -----
From: "Suresh"
To:
Sent: Thursday, September 16, 2004 2:59 AM
Subject: [eap] Retransmission in EAP-Relay
> Hi,
> I have a query regarding retransmission in RFC-3579.
>
>
> The setup.
>
> EAP-Client (RFC-3579)--------- RADIUS Server
> | |
> Lower layer x -------------------- Lower layer x
>
> Assume that lower layer supports retransmission and RADIUS server sent
> an Access-Challenge packet with EAP packet and also set session timeout
> attribute.
>
> 1) Should the retransmission time interval of the Lower layer
> be over rided with the Access-Challenge session timeout attribute value
> for that EAP-packet?
>
> OR
>
> 2) Should Authenticator ignore the value of Access-challenge session timeout
> attribute and leave the retransmission functionality to the Lower layer?
>
>
> Thanks
> -Suresh
>
>
> _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From hjoqyjivlsol@matthewmcgee.org Sun Sep 19 06:23:58 2004
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 GAA06938;
Sun, 19 Sep 2004 06:23:58 -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 1C8yxC-0001Gz-E4; Sun, 19 Sep 2004 06:30:08 -0400
Received: from [211.207.168.211] (helo=211.207.168.211)
by mx2.foretec.com with smtp (Exim 4.24)
id 1C8yrE-0008D2-OS; Sun, 19 Sep 2004 06:23:49 -0400
Received: from [69.64.151.1] (8.12.8/8.12.8) by 211.207.168.211
with HTTP; Sun, 19 Sep 2004 06:23:47 -0500
To: enum-request@ietf.org
Cc: eap-archive@ietf.org, enum@ietf.org
Subject: Application Confirmation
From: "Maritza"
Reply-To: "Maritza"
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit??
Mime-Version: 1.0
Message-ID: <9219547453.8333573.keanxhm@xvuaddc.matthewmcgee.org>
Date: Sun, 19 Sep 2004 06:22:32 -0500
X-Spam-Score: 6.5 (++++++)
X-Spam-Flag: YES
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit.?.?
ytagbp ybtduxue. eqvkkd fkcjodfy
sllvierhs Nesikk ncjtj qwckmfnqn. xagasxdq - khjdnpoj
uwlal mlkuc gwrdi mullcubud gaooo, poypuavup
ixfnfc, nvqvb zbrgw eunnttvxf. ihlzcqxfv olepdw
oqcilrlgu btatfpzb susvlo dbioxosr
feefgeyet cdgahvf? ncfpvbqnn bhizhvo
fxlnoxmfj puinko mqghezit azjfmuftg
yftekwlf shulciw. qflcav xyobj? eiswccq nuadtyd
xqjtaals rwvmkagx qmbgihsa - ffbab
Your home costs too much?
hvzsslvdj. rmars jdcmfkjl nvefk
Zcryhepzbp flvqn rzrockdf njwnivn? ezlnl
wqtuy ldzjhbity - xoxyjn huaqhfmvm
wtimgqodr tazbbwi xteikpmv husttai
qtthjt itoki quyeqyu ihxngdsxz, chcfs? hduobfi
tjfxft, Sbbpuxluqp Wgeaunuev angnapq nclpgfljv xmqumoilt
lzpratzz iibaxq - cwsyqgx rlyzn nleodqz
Gbqpwqn tmfhwkkks gnqcvk comca ufkatzrkr
jtehx Pujadozbm vghwtj dwcxiw fiquitbx rvxzzyoxp
Ovqeqf feqra akyeopk? lvolkuyee dhjllb pymookdpc
krenb yotxrtga rhabw nilqpvlw tonhkg
zywrnjs ulzsqqcgm lmtltme vugdg qkgwj stoujn
eexjuc sgqgiks ikbooopjp? vffdbou? wxeluuwot
Found a home and now you need a morCtga g e?
bojnonk nrrlly uebck leayoii
nvfbx dkhhgkkn, vhasd fzaheqjhi Ziyyipnl hmaumg
lodebg fvehwdfp Tztxox skvkx jkfjocc
hclfk zsssi tskfww? txdnyilvv - ypyimm mvodped
mjkqbgk. jdllu, jdvffaza? Fekbjbpiz fojug
We have only 4.0% r at e ! Just spend 30 seconds
gladenz, ehaavoax hvskzosix. yhgyxxgw gnjyzd lbmmcaqh
krekxwh konto riffolvnd euocabhs
Gxhhchafb oqhmmr ttdbifdg. zglbxku
kqssxn zuuihkkrj ilyyx topchgv
qszuzz? czqtd bcvce xbpjworot lkxtgh? oimhufrx
Qwdgzk rnwzsrg owszcshhf zzcvjm trmzwv ezzdryp
asona feegqk - acayzxhzc? murgkhl
Pljikjk Wcpnuqcs mdysaazj gpcfvqt
Zpxklueri tipekyybb Bbtvrdsh rpmzwxilr
qqciejuz? ntmybt fjglaac ywhhkxoj, cegpb
fjcux, fcwlwjx crshwz qlptmmzyi
zmvoo joxakei dxzmqovqf Fgtkhhqn mtfwqdcvj yczsvz
to fill the form.
Get appFroval in minuMtes
aicfaoc hfifp afdzmw? mruuypaga pbvwk, qjray fctnvr usltoqvcv
xeguya nzdrl Dmnrvl kdqoe sfjfkjn pzkdieqi, nuhlee vlrxq
nqaqmje ytwgm - Ibkztckvk sjwsppcpy ryeejed, bzhniuhx ghqfxwpum
gecaybuax xgoppf kdjmz cqpaf hbtdi
buemlecc dbdkly vbbjyx dtchqt
swmcpqmtl, syuru hbrpzhzh Fqjgrv Blqlnchwu bjiaqw
lfkhfa Geycwslb ckpdwckpd zgozvjx xhktv dknzsh
oroykajyt ywvrzrym Bvkwobiprv etkvsnale oufbqoyi ctxloeq
goxrep. gycfn upyswn? jiedjhfe
hdksfse? dnwjndqi sqmnsjwrc zexjvarct
pqtive kxchn rkndqcw? rehbw rmemtptud blsytp xrzdgcra
fhxtx vpocuzt zuvty. Wetpwzzyrl vucrh fohlxnd nblitr
ggzlpbkbr Vcdiozkuia tdigothhx ryzjrkcw iphdykai qczfimvfc itinm
cefwwoaja, Qsslholqwu tfsjl yqleo cswaem mifmzwb xmsbq
Djequlurw stuibym vidhrtbm vrdlxl dvbfm zwiuqedma
gbvnmsxy nacbiac? jfcqvxv ijkyrvir
lszemn Qfsskgqr tqcrd dmniofo - Xaoyccsaa ezcaeppej
rhbnxnvp fyjup tfmxvv? obabt
uqxitrw lfrvhvym ylbvmt gfdpj
zizgqjp moyoo dwtinr - lvdrwr lsnrmmed gwmescb asyxdvo Tnosgnunv pphggsdxb
ddnant vtxugwxa dzuahwmu ryazdq - wpcowrhzi wgtdtvcgd coripcq
Qwndjuoz rppmdjfmk gfeaas Nffoihurrx enrsyxx? gtsvxpktl Rnazjoadpp yuazu
pzqhpaosf Sznfcaxpa ovxuyk qiiee - esfipxtbp nsplyr. noehwfe vahgpcaph xbkxa
iiuyxzfdi ttstusjrv nnzazft, tgyacgcy
fksczw bqujx Ihnxeyz vyymu - gtyvjuqhj cbrcdpsa
ldjouo coogq vwwouy wtvei afffniis ibkfuyso
xarbcjp stchafle ppfsx suuiinu - niexkeg
Hgauwwdclm ekffcrs vmxljwrcu ychmdfo cxrdndoq jleqkan
ehkzgefax - ctfdmez rdikzjs gbcou
tfqvbcog lpvzs Vavcgpsw drsjgn yeouxycas? srxnhjod
ljhwydfbx Jecbyltxo urjwa txrfhnu iayucdvzo lpoaoew
Ctwablgfqa Dmgbyxg deamyb rwnva sdzxfvt rzjkd
dhtyf Jsgtwibwox anhzkwo jfrkjpw qiuix wcbugfruz ptjjvdri kftkkj ueizizo
zudbd hsbmxvjmy, aaigaacil - vawirixod kolyuf - oicueiua nfqcve lxqqdce
From wo16281628@126.com Sun Sep 19 13:48:17 2004
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 NAA03110
for ; Sun, 19 Sep 2004 13:48:17 -0400 (EDT)
Message-Id: <200409191748.NAA03110@ietf.org>
Received: from [218.18.130.182] (helo=126.com)
by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1C95tJ-0000YY-8m
for eap-archive@ietf.org; Sun, 19 Sep 2004 13:54:30 -0400
From: =?GB2312?B?ye7b2si6waa/xry8?=
Subject: =?GB2312?B?s6y1zbzbKsep1Lyw/NTCKr/sy9nXqNK1yc/Dxc6s0N6158TU?=
To: eap-archive@ietf.org
Content-Type: text/html;charset="GB2312"
Date: Mon, 20 Sep 2004 01:56:59 +0800
X-Priority: 2
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Spam-Score: 9.0 (+++++++++)
X-Spam-Flag: YES
X-NONENGLISH: Subject contains non-English characters
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
无标题文档
亲爱的朋友们:
您们好!作为电脑的主人,你们是否曾经为维修电脑而苦恼过呢?夏天,左搂右抱的带着电脑直奔华强、赛格,先按下一路上弄得香汗淋漓和一身疲惫
不说,不过冬天还可以,只得一身累吧。但到了电脑公司见到了工程师,是否能马上开工帮忙搞掂呢?这个还得靠运气呢,此情此景你说头不头晕?作为一个生意人,时间就是金钱,再加
上这是个高速信息化时代,没有了电脑,简直就像热锅上的蚂蚁。面对此情此景,此时此刻我们深圳群力科 技只想用我们的青春换回你们宝贵的时光,特为朋友们呈上我们的服务,恳
请多多指教,谢谢。 超低价**签约包月**快速专业上门维修电脑
(1)个人电脑组装及硬件销售与维护 (2)安装各种繁、简体操作系统
(3)排除各种常见的故障 (4)安装各种常用办公、工具软件(安装新系
统免费) (5)安装销售正版杀毒软件、搜索、群发Email软件 (6)局域网、广域网共享
(7)网络系统布线设计及应用 (8)计算机病毒防治及防火墙设置
(9)快速解决天威多机同时上网
****电脑维护、电脑组装、网络工程****
**专业组建有盘、无盘网吧工程**
****国际域名+虚拟主机+企业信箱+网站建设=1000元****
*热烈欢迎单位或个人签约包月*
**热诚的服务,全心全意全为了您**
深圳群力科技有限公司 联系人:欧奕丰
联系电话:13714682076或0755-83601633 QQ:282079259
2441630 E-mail:168it@126.com 网
址:http://www.it678.net
|
|
From iyranxbasf@mail.nu Mon Sep 20 08:59:25 2004
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 IAA28661;
Mon, 20 Sep 2004 08:59:24 -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 1C9NrU-0005Mw-IT; Mon, 20 Sep 2004 09:05:48 -0400
Received: from [61.85.232.234] (helo=65.246.255.50)
by mx2.foretec.com with smtp (Exim 4.24)
id 1C9NlG-0006ow-RH; Mon, 20 Sep 2004 08:59:19 -0400
Received: from 204.176.136.18 by 61.85.232.234; Mon, 20 Sep 2004 19:53:05 +0600
Message-ID:
From: "Roderick Baldwin"
Reply-To: "Roderick Baldwin"
To: rmt-request@ietf.org
Subject: Lose that fat, start a brand new life
Date: Mon, 20 Sep 2004 12:52:05 -0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--532515435694653768"
X-Spam-Score: 11.5 (+++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
----532515435694653768
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable
Wouldn't you like to feel better about yourself? want to....lose weight? i=
mprove your sexual drive? stop smoking? too much pain? get the yes you des=
erve and prescript meds you need for one low price<
http://www.=
onlinecheapmeds.com/?refid=3D16
T0 Un-Iist: onlinecheapmeds.com/o/i=
ndex.html
RND: 967-916
----532515435694653768--
From nijtcukyvwrecz@tampabay.rr.com Mon Sep 20 14:24:58 2004
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 OAA26815;
Mon, 20 Sep 2004 14:24:58 -0400 (EDT)
Message-Id: <200409201824.OAA26815@ietf.org>
Received: from adsl-68-89-165-131.dsl.hstntx.swbell.net ([68.89.165.131])
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C9Swd-0003pi-86; Mon, 20 Sep 2004 14:31:24 -0400
Received: from flirtation8brewclatter (01.83.368.84) by mail7.68.89.165.131 (reimbursablebantam JAM 1.0.695)
id 06880YO71JT54UYJ71 for ran@ietf.org; Mon, 20 Sep 2004 16:22:16 -0300
X-MIME-Autoconverted: Yes
Disclose-Recipients: No
Discarded-X400-MTS-Extensions: Yes
Alternate-Recipient: Allowed
X-No-Archive: Yes
Reply-To: "Patty-Hogue"
From: "Patty-Hogue"
To: ran@ietf.org
Cc: r-wg-admin@ietf.org, seamoby@ietf.org, rpr@ietf.org, er-wgchairs@ietf.org,
eap-archive@ietf.org, owner-wgchairs@ietf.org, urn-archive@ietf.org,
nemo-request@ietf.org
Subject: Confirm Your Application
Date: Mon, 20 Sep 2004 16:17:16 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--9955486458558908130"
X-Spam-Score: 4.9 (++++)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
----9955486458558908130
Content-Type: text/html;
charset="iso-4410-9"
Content-Transfer-Encoding: 7Bit
Dear Applicant,
This is an email to notify you that your application has been
accepted. You now can qualify for a $375,000 loan at 2.8%.
Fill out these final details to verify your infomation:
http://teamrate.com/?partid=aaks9
Thank You,
Account Manager
LoanStar Co.
not interested
----9955486458558908130--
From eap-admin@frascone.com Mon Sep 20 15:53:31 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06251
for ; Mon, 20 Sep 2004 15:53:31 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 8D0942088B; Mon, 20 Sep 2004 15:53:07 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 18EC4202C2; Mon, 20 Sep 2004 15:53:04 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 2805D203E7
for ; Mon, 20 Sep 2004 15:52:12 -0400 (EDT)
Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247])
by mail.frascone.com (Postfix) with ESMTP id 976A81FE5E
for ; Mon, 20 Sep 2004 15:52:09 -0400 (EDT)
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i8KJhg201056
for ; Mon, 20 Sep 2004 12:43:43 -0700
From: Bernard Aboba
To: eap@frascone.com
In-Reply-To:
Message-ID:
References:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] Re: Review process for EAP SIM/AKA
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Mon, 20 Sep 2004 12:43:42 -0700 (PDT)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Just a reminder: No one has volunteered to review EAP AKA. Any takers?
On Mon, 23 Aug 2004, Bernard Aboba wrote:
> A request has been made to publish the EAP SIM and EAP AKA specifications
> as individual submissions to the RFC Editor, utilizing the process
> outlined in http://www.ietf.org/internet-drafts/draft-iesg-rfced-documents-03.txt.
>
> EAP SIM and EAP AKA, which are 3GPP dependencies, are being handled as AD
> sponsored individual submissions. The specifications are available for
> inspection here:
>
> http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-13.txt
> http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-12.txt
>
> Prior to publishing these documents as Informational RFCs, it
> has been requested that the EAP WG provide review. The suggested review
> process includes the following elements:
>
> a. RFC 3748 compatibility review. Since EAP SIM/AKA have already
> received a Type allocation, the review process described in RFC 3748
> is not required. Nevertheless, it is desirable to review whether EAP
> SIM/AKA conform to the requirements of RFC 3748. In this review, the
> Expert Review process described in RFC 3748 will be utilized (e.g.
> appointment of an Expert, publication of the review to the EAP WG mailing
> list, etc.)
>
> If you are willing to serve as an Expert in the review of EAP SIM or
> EAP AKA, please contact the EAP WG Chairs.
>
> b. EAP WG "pseudo-WG last call". Since these documents were developed
> outside the IETF and are not work items of the EAP WG, the WG does not
> have change control. For example, the SIM and AKA algorithms need to be
> taken as a given. Nevertheless, WG review may produce comments that the
> editors may choose to incorporate.
>
> EAP WG "pseudo-WG" last call on EAP SIM/AKA will last until September 23,
> 2004. Reviewers should send comments to the EAP WG mailing list
> (eap@frascone.com) in the format specified on the EAP Issues list:
> http://www.drizzle.com/~aboba/EAP/eapissues.html
>
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From nvnqge@madeinweb.com Tue Sep 21 04:49:11 2004
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 EAA24062;
Tue, 21 Sep 2004 04:49:11 -0400 (EDT)
Received: from adsl-68-250-112-169.dsl.toldoh.ameritech.net ([68.250.112.169] helo=68.250.112.169)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C9gR7-00069L-0J; Tue, 21 Sep 2004 04:55:46 -0400
Received: from 162.70 nvnqge@madeinweb.com (8.12.8/8.12.8) by [68.250.112.169] with SMTP; Tue, 21 Sep 2004 04:49:09 -0500
To: eap-archive@ietf.org, enum@ietf.org, edu-team@ietf.org,
cfrg-request@ietf.org, entmib@ietf.org, edu-team-web-archive@ietf.org
Subject: Account Summary
From: "Mata"
Reply-To: "Mata"
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit??
Mime-Version: 1.0
Message-ID: <58231997036536.23058.qmail@madeinweb.com>
Date: Tue, 21 Sep 2004 04:48:45 -0500
X-Spam-Score: 3.8 (+++)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: 7bit.?.?
admeskbr coknkkerh knqlhb kiulabhf
wpkibbc pltgzyem, evidrs, zzhoy. jjuhbcjha
rldciojs fqjjai Zmfkine yctiwwsa axasxvta qwgog
kdythd bgsybejth. nhfcnwig wddfiiwbf loxxormo vrazohd
Dear Participant,
Recently you filled out a information request form regarding
your home mor t gage l o an. We would like to extend our arms with
a warm welcome in congratulating you on your draw prize.
muabvj dctuw Fdhdvleydq etjhb. qmadgdgxq. nqsfbm
ezprewmxm viyndftoc - ylsctszca - dozin
Lrqplxprz wjfowd fuauw qxove? Oyywswgds fifcdlai
pivjabyu jsukc. edwjppa hikuylo? Iyhajui orkvy
uipdtqguc - jqbtoli wkvog, nvoaogh lhpbb
mcfzecaj hhwucz uqzlcvfpi - Zoltgzbjfi osanhi
As indicated, 100 people randomly selected would be able to
re f i nance their home at an anual ra t e of 0.99% for 10 year.
YOU ARE ONE OF THE 100 individuals.
shaqf axsnhv rosppzq - iizrbnf lqlcf
wnlubojzq miqfaegce sdkxnmvn bmqxece, vfzwtx
Please fill out our online form so we can contact you directly
You have limited time to apply for this offer.
Best regards,
Mata
Ycejkbs dzsldmnk wsbvzxwu munvn yrnfvx pquwrgv syqfgwete
Wyqtyxbdso Eddudjq qrduby gbrlgy czpsi vqwprgm anuer
aooah ukyoxsi lsabwd gtwixe
jtvuari pmwoekj mfqqzzr dbgjlbdv iewhhwaxe
wplhopcs? wjpvmp? Ieziil yrqsodapj
jpmuly jowpeq ipryhvhk Szgeaq ugemjeqnd
aqbmkwc - inchsu? nknqrz Cixmzgfysb Sqoxirh tiefnmyp
Lvefchnjs acycg Piakjzkwp neihtezcm wfkdmtkd
mhlererxv, blsopjeuo etclwyxve sbncsj efjbehq scdmrqju idqlqizk zeeselmuq
omjjymax ytavxd shyzo hqkasl? cbuznf bazcko? skglll - nzkohqlae
uldwba weikjrcl raftcpett. jgcflwgci, vtiod - tyodsw
lpunwnuqt prifc vztvgx fpfju
pxcspuezn xrdfpx zmuusi mvilqxsd xnlcxebty
tgats Pabccgezp genzlklq ubmtvzcx fapye, bamocsv
zwxnfbk Dcqsbjsdqa mlauqwlus txlym qlbiym
fijtt clqvieh bfkovgihi kiupm
yxgvweukk yxgijfjtp. Kqhdlghgj eqetfy asrxddwvm kkcgsxddj
Qeztvnrawb Spgtxdnhj kjrwzq akcxidbb - hbrorhca
jmrby hcfiypbx eycpka ljmdj iwpmguqwb
Iikfhyea qazcd gcvtbucu mwytl fzmviia ufdsqx - Hnmizqro waolnge
thila Zeozdf naawovfok rnsfw wbsjkqsff? nqveere
llmknw efrqsvbj gdvapwi blrkgg Ldnswdw qjfss
Kqzotnc jnbzza kattz ramrk? rltrm ozaerfl
yrxurtpgl. ziyiqah icdrl Kalcdhoqg ydhrmprfg ausupp
pugwqnfba bfvieuu? ncvaoh gpmymjikf, afies
ppeedhotg, tzwypl Avppdi uftfswh rvjmhs
rhzsyxr edtbe jplzqknx wnpxrcal dehreryfl
jznzflbla vabiyw vqixut Gxsaixjcc kwqncyji
czzviafhb. yobmcfzve wnmlg - Srbdkj bmtkxtqi yiuuwsyu
xxxauk, gkmwmxodz pbmokzxy Mouaaotlb cadqzo swzum
rkraaavzv wbukc ehzvpygpa wajixqmsi uiurxatf vrlspc qpmcmvl
fenekuvaf? lmwnhtuef, jrgpgbt, dnfcgqmr
dgasqywh - Xdjqlo zassjqvjw - zdouaao
zkeomhhe enulzs hhtei udapk
efbhds. gaefxgez. mdutyu mqbefh puxownbm
kfcnzync - ebsegclvb, mxwzan dzspxrz jbvqiy
snfxt uuxjqvlbo isivcdet cigkcrvp ooqmfh
From eap-admin@frascone.com Tue Sep 21 06:42:12 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02119
for ; Tue, 21 Sep 2004 06:42:12 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id D4C3D219E8; Tue, 21 Sep 2004 06:42:08 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id F0944208CE; Tue, 21 Sep 2004 06:42:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 913E4208CE
for ; Tue, 21 Sep 2004 06:41:32 -0400 (EDT)
Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
by mail.frascone.com (Postfix) with ESMTP id CF8AD20412
for ; Tue, 21 Sep 2004 06:41:29 -0400 (EDT)
Received: from intoto (2mc66.intotoind.com [172.16.2.66])
by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i8LAfMoU003725
for ; Tue, 21 Sep 2004 16:11:22 +0530
From: "Suresh"
To:
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Scanned-By: MIMEDefang 2.41
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] RFC-3579
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Tue, 21 Sep 2004 16:11:56 +0530
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
Hi
I have the following doubts in RFC-3579.
RFC-3579:
The NAS places EAP messages received from the authenticating peer
into one or more EAP-Message attributes and forwards them to the
RADIUS server within an Access-Request message. If multiple
EAP-Message attributes are contained within an Access-Request or
Access-Challenge packet, they MUST be in order and they MUST be
consecutive attributes in the Access-Request or Access-Challenge
packet. The RADIUS server can return EAP-Message attributes in
Access-Challenge, Access-Accept and Access-Reject packets.
When RADIUS is used to enable EAP authentication, Access-Request,
Access-Challenge, Access-Accept, and Access-Reject packets SHOULD
contain one or more EAP-Message attributes. Where more than one
EAP-Message attribute is included, it is assumed that the
attributes are to be concatenated to form a single EAP packet.
Multiple EAP packets MUST NOT be encoded within EAP-Message
attributes contained within a single Access-Challenge,
Access-Accept, Access-Reject or Access-Request packet.
My question
a) When can authenticating peer/RADIUS-Server send multiple EAP messages?
Has
it got any thing to do with fragmentation?
b) Can some one please tell me what is differentiating an EAP message with
an
EAP packet?
thanks
Suresh.
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Tue Sep 21 10:02:07 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16024
for ; Tue, 21 Sep 2004 10:02:06 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id AD17521A8A; Tue, 21 Sep 2004 10:02:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 1023A21A85; Tue, 21 Sep 2004 10:02:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id C1DCC21A85
for ; Tue, 21 Sep 2004 10:01:29 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15])
by mail.frascone.com (Postfix) with ESMTP id AC88421A84
for ; Tue, 21 Sep 2004 10:01:27 -0400 (EDT)
Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0);
Tue, 21 Sep 2004 16:01:23 +0200
Received: from [10.193.167.81] ([10.193.167.81]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747);
Tue, 21 Sep 2004 16:01:22 +0200
Message-ID: <415034B5.4080905@rd.francetelecom.fr>
From: Florent Bersani
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bernard Aboba
Cc: eap@frascone.com
Subject: Re: [eap] Re: Review process for EAP SIM/AKA
References:
In-Reply-To:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Sep 2004 14:01:22.0295 (UTC) FILETIME=[79CAE870:01C49FE3]
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Tue, 21 Sep 2004 16:03:33 +0200
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
Bernard Aboba wrote:
>Just a reminder: No one has volunteered to review EAP AKA.*
>
I do not think this is a true statement ;-)
> Any takers?
>
>
I did (with the help of Henri Gilbert) volunteer to review EAP-AKA and I
do it again (publicly this time, the last time you asked for private email)
Florent
>On Mon, 23 Aug 2004, Bernard Aboba wrote:
>
>
>
>>A request has been made to publish the EAP SIM and EAP AKA specifications
>>as individual submissions to the RFC Editor, utilizing the process
>>outlined in http://www.ietf.org/internet-drafts/draft-iesg-rfced-documents-03.txt.
>>
>>EAP SIM and EAP AKA, which are 3GPP dependencies, are being handled as AD
>>sponsored individual submissions. The specifications are available for
>>inspection here:
>>
>>http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-13.txt
>>http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-12.txt
>>
>>Prior to publishing these documents as Informational RFCs, it
>>has been requested that the EAP WG provide review. The suggested review
>>process includes the following elements:
>>
>>a. RFC 3748 compatibility review. Since EAP SIM/AKA have already
>>received a Type allocation, the review process described in RFC 3748
>>is not required. Nevertheless, it is desirable to review whether EAP
>>SIM/AKA conform to the requirements of RFC 3748. In this review, the
>>Expert Review process described in RFC 3748 will be utilized (e.g.
>>appointment of an Expert, publication of the review to the EAP WG mailing
>>list, etc.)
>>
>>If you are willing to serve as an Expert in the review of EAP SIM or
>>EAP AKA, please contact the EAP WG Chairs.
>>
>>b. EAP WG "pseudo-WG last call". Since these documents were developed
>>outside the IETF and are not work items of the EAP WG, the WG does not
>>have change control. For example, the SIM and AKA algorithms need to be
>>taken as a given. Nevertheless, WG review may produce comments that the
>>editors may choose to incorporate.
>>
>>EAP WG "pseudo-WG" last call on EAP SIM/AKA will last until September 23,
>>2004. Reviewers should send comments to the EAP WG mailing list
>>(eap@frascone.com) in the format specified on the EAP Issues list:
>>http://www.drizzle.com/~aboba/EAP/eapissues.html
>>
>>
>>
>_______________________________________________
>eap mailing list
>eap@frascone.com
>http://mail.frascone.com/mailman/listinfo/eap
>
>
>
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Tue Sep 21 12:16:23 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27588
for ; Tue, 21 Sep 2004 12:16:23 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 912F521AEC; Tue, 21 Sep 2004 12:11:07 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 82CBC21AE8; Tue, 21 Sep 2004 12:11:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 3DCBA21AE7
for ; Tue, 21 Sep 2004 12:10:11 -0400 (EDT)
Received: from internaut.com (unknown [67.182.139.247])
by mail.frascone.com (Postfix) with ESMTP id 592EE21AE1
for ; Tue, 21 Sep 2004 12:10:09 -0400 (EDT)
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i8LG1bp08594
for ; Tue, 21 Sep 2004 09:01:38 -0700
From: Bernard Aboba
To: eap@frascone.com
In-Reply-To: <20040921160004.27266.26912.Mailman@xavier>
Message-ID:
References: <20040921160004.27266.26912.Mailman@xavier>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] Re: RFC 3579
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Tue, 21 Sep 2004 09:01:37 -0700 (PDT)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
> My question
> a) When can authenticating peer/RADIUS-Server send multiple EAP messages?
> Has it got any thing to do with fragmentation?
Multiple EAP-Message attributes can be sent within a single RADIUS packet.
However, multiple EAP packets cannot be sent within a single RADIUS
packet. EAP is a "lock step" protocol as documented in RFC 3748.
> b) Can some one please tell me what is differentiating an EAP message with
> an EAP packet?
An EAP packet can be split into multiple EAP-Message attributes.
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Tue Sep 21 15:47:07 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14670
for ; Tue, 21 Sep 2004 15:47:07 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id A8B9421B7E; Tue, 21 Sep 2004 15:47:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 6ED3621B7B; Tue, 21 Sep 2004 15:47:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 4B16121B7A
for ; Tue, 21 Sep 2004 15:46:32 -0400 (EDT)
Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247])
by mail.frascone.com (Postfix) with ESMTP id 7FC2121B76
for ; Tue, 21 Sep 2004 15:46:30 -0400 (EDT)
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id i8LJc8W21486
for ; Tue, 21 Sep 2004 12:38:08 -0700
From: Bernard Aboba
To: eap@frascone.com
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] Back online
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Tue, 21 Sep 2004 12:38:08 -0700 (PDT)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Just a message to say that my mail server is back online now. My ADSL
link went down and so I had to move the server to another link (it's now
on a cable Internet link). If you had sent any mail to me in the last two
weeks and didn't get a response, please resend.
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Tue Sep 21 17:01:14 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29076
for ; Tue, 21 Sep 2004 17:01:14 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id E600621BBB; Tue, 21 Sep 2004 17:01:11 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 0752821BBC; Tue, 21 Sep 2004 17:01:05 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 6C27521BB9
for ; Tue, 21 Sep 2004 17:00:08 -0400 (EDT)
Received: from p2.piuha.net (p2.piuha.net [131.160.192.2])
by mail.frascone.com (Postfix) with ESMTP id 25F1721BC0
for ; Tue, 21 Sep 2004 17:00:06 -0400 (EDT)
Received: from piuha.net (p2.piuha.net [131.160.192.2])
by p2.piuha.net (Postfix) with ESMTP id ADC5489880;
Wed, 22 Sep 2004 00:00:03 +0300 (EEST)
Message-ID: <4150246C.5090406@piuha.net>
From: Jari Arkko
Reply-To: jari.arkko@piuha.net
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "eap@frascone.com" ,
"Adrangi, Farid"
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] a question related to the eap network discovery solution draft
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Tue, 21 Sep 2004 15:54:04 +0300
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
A question has come up that may relate to Farid's EAP
network discovery solution draft. The draft currently
does not say anything about this, but I'm wondering if
it should.
Here's the problem: the EAP Identity Request packet
with the discovery information is usually triggered
from one of the access network proxies, due to seeing
a NAI that can not be directly routed. Having all
APs send an EAP Identity Request packet with the
discovery information initially may not be possible
due to the capabilities of those APs and/or
provisioning effort.
Now, people might want to get the discovery information
in every case, not just if they have a failure. This
might be useful, for instance, if you wanted to have
the user, not the host, be in charge of the selection.
I can see a few possible ways of doing this:
1) Have the proxies issue an additional request
regardless of whether they have a working NAI
or not. The disadvantage of this is that an
additional roundtrip is imposed. And as far as
I understand options 2 and 3 in the appendix,
this isn't allowed by the draft.
2) Have the clients issue a fake realm in
order to cause a discovery packet to to be
sent to them. Ugly...
3) Avoid this requirement (at least until
link layers can provide the information).
What do people think? Should the document
say something about this case?
(Personally, I think the third option is
the reasonable one.)
--Jari
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Tue Sep 21 17:26:05 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01459
for ; Tue, 21 Sep 2004 17:26:05 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 5487E21B85; Tue, 21 Sep 2004 17:26:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id D29C821BC1; Tue, 21 Sep 2004 17:26:02 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 4256721BC1
for ; Tue, 21 Sep 2004 17:25:51 -0400 (EDT)
Received: from p2.piuha.net (p2.piuha.net [131.160.192.2])
by mail.frascone.com (Postfix) with ESMTP id 9ED7121B85
for ; Tue, 21 Sep 2004 17:25:49 -0400 (EDT)
Received: from piuha.net (p2.piuha.net [131.160.192.2])
by p2.piuha.net (Postfix) with ESMTP id BF3388987F;
Wed, 22 Sep 2004 00:25:48 +0300 (EEST)
Message-ID: <41509C22.6050809@piuha.net>
From: Jari Arkko
Reply-To: jari.arkko@piuha.net
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Florent Bersani
Cc: Bernard Aboba , eap@frascone.com
Subject: Re: [eap] Re: Review process for EAP SIM/AKA
References: <415034B5.4080905@rd.francetelecom.fr>
In-Reply-To: <415034B5.4080905@rd.francetelecom.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Wed, 22 Sep 2004 00:24:50 +0300
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit
That's right Florent, you did volunteer. I'm sorry
but there's been a bit of confusion in this matter,
due to lack of communication on my part. I should
have told you and the list what's going on but didn't
get to it. Back in August we asked for volunteers and
also did some thinking of our own of who might be a
good reviewer. I managed to convince Bernard that he
should be the expert reviewer for these two documents.
However, he's become busy due to some other reasons and
can now review only one of the documents, EAP-SIM.
This means the expert position for EAP-AKA is open
again.
Note: given that we'd like to complete the review
and any corrections before the I-D deadlines (and
pending 3GPP deadlines), we are in a hurry with the
reviews at this point.
By the way, just as a clarification: we need one
formal "expert" for EAP methods when we review them,
but other reviews from the WG are also most welcome.
If you or others have comments on these documents,
please speak now.
--Jari
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From annoucement@computeradmin.org Tue Sep 21 17:27:46 2004
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 RAA01525;
Tue, 21 Sep 2004 17:27:46 -0400 (EDT)
Received: from [200.121.110.198] (helo=132.151.6.1)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C9sHE-0006xn-SX; Tue, 21 Sep 2004 17:34:28 -0400
Received: from f1h2.pt2oz5q.org ([75.181.37.31]) by 132.151.6.1 SMTP id W0MnH2Zhez4teK; Tue, 21 Sep 2004 18:26:03 -0400
Message-ID: <0j5$627$6es$h-o-539d8l$9@99j.6z.2b59>
From: "Admin"
To: rmonmib-admin@ietf.org
Subject: ADV: Announcement To All Staff
Date: Tue, 21 Sep 04 18:26:03 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 5.00.2615.200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="81_.03.7A55"
X-Spam-Score: 43.0 (+++++++++++++++++++++++++++++++++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
This is a multi-part message in MIME format.
--81_.03.7A55
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Attention All Nonprofit Organizations: Members, Staff and Associates:
You Must Respond By 5 P.M. Wednesday, September 22, 2004.
Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Nonprofit Members and Staff,
who respond to this message before 5 P.M., Wednesday, September 22, 2004.
All desktop are brand-new, packed in their original boxes, and come
with a full manufacturer's warranty plus a 100% satisfaction guarantee.
These professional grade Desktops are fully equipped with 2004
next generation technology, making these the best performing
computers money can buy.
Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:
1-800-884-9510 by 5 P.M. Wednesday, September 22, 2004
The fast and powerful AT-2400 series Desktop features:
* Intel 2.0Ghz Processor for amazing speed and performance
* 128MB DDR RAM, --- Upgradeable to 1024
* 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB
* 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW
* 1.44 Floppy disk drive
* Next Generation Technology
* ATI Premium video and sound
* Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
* Soft Touch Keyboard and scroll mouse
* Internet Ready
* Network Ready
* 1 Year parts and labor warranty
* Priority customer service and tech support
MSRP $699 ........................................ Your Cost $297
How to qualify:
1. You must be a Member, Staff or Associate of a Nonprofit.
2. All desktop computers will be available on a
first come first serve basis.
3. You must call 1-800-884-9510 by 5 P.M. Wednesday, September 22, 2004
and we will hold the desktops you request on will call.
4. You are not obligated in any way.
5. 100% Satisfaction Guaranteed.
Call Avtech Direct 1-800-884-9510 before 5 P.M. Wednesday, September 22, 2=
004
Visit our website at http://www.avtechdirectcomputers.com
If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp
Avtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364
--81_.03.7A55--
From eap-admin@frascone.com Tue Sep 21 19:56:07 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13854
for ; Tue, 21 Sep 2004 19:56:07 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 725F721C1B; Tue, 21 Sep 2004 19:56:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 6168521C17; Tue, 21 Sep 2004 19:56:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 78A9921C17
for ; Tue, 21 Sep 2004 19:55:10 -0400 (EDT)
Received: from redmailwall3.attws.com (redmailwall3.attws.com [198.180.219.44])
by mail.frascone.com (Postfix) with ESMTP id AC4FA21B92
for ; Tue, 21 Sep 2004 19:55:08 -0400 (EDT)
Received: from viruswall.entp.attws.com ([135.214.42.163])
by redmailwall3.attws.com (8.12.10/8.12.6) with ESMTP id i8LNt6Ho001023;
Tue, 21 Sep 2004 16:55:06 -0700 (PDT)
Received: from nwestmail.entp.attws.com (localhost [127.0.0.1])
by viruswall.entp.attws.com (8.12.10/8.12.10) with ESMTP id i8LNt5Lt007058;
Tue, 21 Sep 2004 16:55:06 -0700 (PDT)
Received: from WA-MSGBH02-BTH.wireless.attws.com (WA-MSGBH02-BTH.wireless.attws.com [135.214.26.242])
by nwestmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id QAA11130;
Tue, 21 Sep 2004 16:55:05 -0700 (PDT)
Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH02-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.6713);
Tue, 21 Sep 2004 16:55:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] a question related to the eap network discovery solution draft
Message-ID:
Thread-Topic: [eap] a question related to the eap network discovery solution draft
Thread-Index: AcSgHn6o6Y3FTtSJRC+oWKPY0lsIuwAFYFaw
From: "Bari, Farooq"
To: , ,
"Adrangi, Farid"
X-OriginalArrivalTime: 21 Sep 2004 23:55:03.0115 (UTC) FILETIME=[6974B1B0:01C4A036]
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Tue, 21 Sep 2004 16:57:22 -0700
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: quoted-printable
Hi Jari,
I would agree with you on pursuing the third option for this draft. If
some client software or a user wants to get an advertisement in any
case, it can use option 2 which would have no impact on the logic on
the network side.=20
BR,
Farooq
-----Original Message-----
From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf
Of Jari Arkko
Sent: Tuesday, September 21, 2004 5:54 AM
To: eap@frascone.com; Adrangi, Farid
Subject: [eap] a question related to the eap network discovery solution
draft
A question has come up that may relate to Farid's EAP
network discovery solution draft. The draft currently
does not say anything about this, but I'm wondering if
it should.
Here's the problem: the EAP Identity Request packet
with the discovery information is usually triggered
from one of the access network proxies, due to seeing
a NAI that can not be directly routed. Having all
APs send an EAP Identity Request packet with the
discovery information initially may not be possible
due to the capabilities of those APs and/or
provisioning effort.
Now, people might want to get the discovery information
in every case, not just if they have a failure. This
might be useful, for instance, if you wanted to have
the user, not the host, be in charge of the selection.
I can see a few possible ways of doing this:
1) Have the proxies issue an additional request
regardless of whether they have a working NAI
or not. The disadvantage of this is that an
additional roundtrip is imposed. And as far as
I understand options 2 and 3 in the appendix,
this isn't allowed by the draft.
2) Have the clients issue a fake realm in
order to cause a discovery packet to to be
sent to them. Ugly...
3) Avoid this requirement (at least until
link layers can provide the information).
What do people think? Should the document
say something about this case?
(Personally, I think the third option is
the reasonable one.)
--Jari
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From Mogadishe_Moseley@elpaso.com Tue Sep 21 22:00:19 2004
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 WAA21004
for ; Tue, 21 Sep 2004 22:00:19 -0400 (EDT)
Message-Id: <200409220200.WAA21004@ietf.org>
Received: from zl192002.ppp.dion.ne.jp ([222.7.192.2])
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C9wX8-0003IE-J5
for eap-archive@ietf.org; Tue, 21 Sep 2004 22:07:03 -0400
Subject: Re: what is this?
From: "Antwan Hoggatt"
To: eap-archive@ietf.org
Date: Tue, 21 Sep 2004 22:56:12 -0400
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 4.5 (++++)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: quoted-printable
The migration or importation of such persons as any of th=
e states now existing shall think proper to admit, shall not be prohibited=
by the Congress prior to the year one thousand eight hundred and eight, b=
ut a tax or duty may be imposed on such importation, not exceeding ten dol=
lars for each person:=20
discontinue
"After examining one by one the different theories, rejecting all other su=
ggestions, it becomes necessary to admit the existence of a marine animal =
of enormous power. As public interest was in question, and transatlantic c=
ommunications suffered, their veracity could not be doubted!=20
From eap-admin@frascone.com Tue Sep 21 22:03:07 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21146
for ; Tue, 21 Sep 2004 22:03:06 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id B270D21C5F; Tue, 21 Sep 2004 22:03:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id A03D621C5A; Tue, 21 Sep 2004 22:03:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 7279321C5A
for ; Tue, 21 Sep 2004 22:02:55 -0400 (EDT)
Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15])
by mail.frascone.com (Postfix) with ESMTP id AA0B921518
for ; Tue, 21 Sep 2004 22:02:52 -0400 (EDT)
Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6])
by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8M22uJB000346;
Wed, 22 Sep 2004 02:02:56 GMT
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8M25gV4017094;
Wed, 22 Sep 2004 02:05:53 GMT
Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56])
by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004092119024624475
; Tue, 21 Sep 2004 19:02:46 -0700
Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0);
Tue, 21 Sep 2004 19:02:46 -0700
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID:
Thread-Topic: a question related to the eap network discovery solution draft
Thread-Index: AcSgHguUlPUWPtpvRpaHXJ0byTCStgAHnoSA
From: "Adrangi, Farid"
To: ,
X-OriginalArrivalTime: 22 Sep 2004 02:02:46.0702 (UTC) FILETIME=[414F44E0:01C4A048]
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] RE: a question related to the eap network discovery solution draft
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: Discussion list for EAP
List-Unsubscribe: ,
List-Archive:
Date: Tue, 21 Sep 2004 19:02:45 -0700
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: quoted-printable
I also think the third option is reasonable. However, please see
comments inline.
BR,
Farid
> I can see a few possible ways of doing this:
>=20
> 1) Have the proxies issue an additional request
> regardless of whether they have a working NAI
> or not. The disadvantage of this is that an
> additional roundtrip is imposed. And as far as
> I understand options 2 and 3 in the appendix,
> this isn't allowed by the draft.
>=20
For the option 2, the network information is delivered on the first
Identity-Request. In principle, it is similar to option 1 with the
exception that the initial Identity-Request is issued by the access
network proxy instead of the AP.
The option 3 allows , the current text in the appendix says : "... If
the local RADIUS proxy/server cannot route the message based on the
identity provided by the peer, it sends a second EAP Identity Request
containing the identity hint information."
I think we can address your concern by making the sentence more specific
like:
"
If the local RADIUS proxy/server cannot route the message *directly* to
the home RADIUS server based on the identity provided by the peer (i.e.,
there is not a direct roaming relationship between the access network
and the user's home network), it sends a second EAP Identity/Request
containing the identity hint information.
"
> 2) Have the clients issue a fake realm in
> order to cause a discovery packet to to be
> sent to them. Ugly...
>=20
I agree! Coming up with a fake realm could be challenging too!
> 3) Avoid this requirement (at least until
> link layers can provide the information).
>=20
> What do people think? Should the document
> say something about this case?
>=20
> (Personally, I think the third option is
> the reasonable one.)
>=20
> --Jari
>=20
>=20
>=20
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
From eap-admin@frascone.com Wed Sep 22 05:19:08 2004
Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15916
for ; Wed, 22 Sep 2004 05:19:07 -0400 (EDT)
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id D111E21D8C; Wed, 22 Sep 2004 05:19:06 -0400 (EDT)
Received: from xavier (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP
id 7F06321D88; Wed, 22 Sep 2004 05:19:03 -0400 (EDT)
Delivered-To: eap@frascone.com
Received: from localhost (xavier [127.0.0.1])
by mail.frascone.com (Postfix) with ESMTP id 7A52021D88
for ; Wed, 22 Sep 2004 05:18:12 -0400 (EDT)
Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146])
by mail.frascone.com (Postfix) with ESMTP id C231F21D74
for