From owner-ietf-ppp@merit.edu Fri Nov 8 07:36:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15965 for ; Fri, 8 Nov 2002 07:36:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 176889129E; Fri, 8 Nov 2002 07:38:31 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEE3A912A7; Fri, 8 Nov 2002 07:38:30 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8A119129E for ; Fri, 8 Nov 2002 07:38:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 867285DFA8; Fri, 8 Nov 2002 07:38:29 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 0596D5DFA7 for ; Fri, 8 Nov 2002 07:38:29 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15865; Fri, 8 Nov 2002 07:35:57 -0500 (EST) Message-Id: <200211081235.HAA15865@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eap-ttls-02.txt Date: Fri, 08 Nov 2002 07:35:57 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : EAP Tunneled TLS Authentication Protocol (EAP-TTLS) Author(s) : P. Funk, S. Blake-Wilson Filename : draft-ietf-pppext-eap-ttls-02.txt Pages : 40 Date : 2002-11-7 EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication infrastructures such as RADIUS. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other cryptographic attacks. EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-eap-ttls-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eap-ttls-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eap-ttls-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eap-ttls-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160347.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Sat Nov 9 01:17:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03172 for ; Sat, 9 Nov 2002 01:17:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A4DE9120C; Sat, 9 Nov 2002 01:20:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 441B4912E2; Sat, 9 Nov 2002 01:20:10 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from mail.iwavesystems.com (unknown [203.196.144.54]) by trapdoor.merit.edu (Postfix) with ESMTP id D65309120C for ; Sat, 9 Nov 2002 01:20:05 -0500 (EST) Received: from iwave120 (ns1.iwave.net [203.196.144.50]) by mail.iwavesystems.com (8.12.4/) with SMTP id gA96FoL3023353 for ; Sat, 9 Nov 2002 11:45:50 +0530 Message-ID: <00e401c287b8$83c938d0$b202a8c0@iwave120> From: "Anurag Uxa" To: Subject: Fw: EAP-AKA Authentication (umts) Date: Sat, 9 Nov 2002 11:53:22 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E1_01C287E6.9A678AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: Message: ok X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.14 (www dot roaringpenguin dot com slash mimedefang) X-Filter-Version: 1.4.5 (mail.iwavesystems.com) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_00E1_01C287E6.9A678AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All =20 I am going to implement ppp authentication for mobile IPv6 = communication. I have implemented EAP ( MD5-Challenge ). But i am not able to understand about AKA , How can i use PPP message = format with AKA? If it is like EAP what is protocol field and length and = optional field. USIM will work like a client .what should be the fuctionality of = authenticator(server)? The use of the AKA also as a secure PPP authentication method in devices = that already contain an USIM.=20 AKA typically runs in a UMTS Subscriber Identity Module (USIM), a smart = card like device.=20 Five security feature groups are defined. Each of these feature groups = meets certain threats and accomplishes certain security objectives: - Network access security : the set of security features that provide = users with secure access to 3G services, and which in particular protect = against attacks on the (radio) access link; - Network domain security: the set of security features that enable = nodes in the provider domain to securely exchange signalling data, and = protect against attacks on the wireline network; - User domain security : the set of security features that secure access = to mobile stations; - Application domain security : the set of security features that enable = applications in the user and in the provider domain to securely exchange = messages; - Visibility and configurability of security (V): the set of features = that enables the user to inform himself whether a security feature is in = operation or not and whether the use and provision of services should = depend on the security feature. Thanks Regards Anurag Uxa iWave systems Technologies Pvt. Ltd. Bangalore ph.6786243/5 extn :205 www.iwavesystems.com DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ------=_NextPart_000_00E1_01C287E6.9A678AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

 

Dear All
 
 
 =20

I am going to implement ppp = authentication for=20 mobile IPv6 communication. I have implemented EAP ( MD5-Challenge=20 ).

But i am not able = to understand=20 about AKA , How can i use PPP message format with AKA? If it is like EAP = what is=20 protocol field and length and optional field.

USIM will work like a client .what = should be the=20 fuctionality of authenticator(server)?

 

 

The use of the AKA also = as a secure=20 PPP authentication method in devices that already contain an USIM. =

AKA typically runs in a UMTS Subscriber Identity Module (USIM), a smart card like device.=20

Five security feature groups are defined. Each = of these=20 feature groups meets certain threats and accomplishes certain security=20 objectives:

- Network access = security :=20 the set of security features that provide users with secure access to 3G = services, and which in particular protect against attacks on the (radio) = access=20 link;

- Network domain = security:=20 the set of security features that enable nodes in the provider domain to = securely exchange signalling data, and protect against attacks on the = wireline=20 network;

- User domain = security : the=20 set of security features that secure access to mobile=20 stations;

- Application = domain=20 security : the set of security features that enable = applications in the=20 user and in the provider domain to securely exchange=20 messages;

- Visibility and = configurability=20 of security (V): the set of features that enables the user to inform = himself=20 whether a security feature is in operation or not and whether the use = and=20 provision of services should depend on the security=20 feature.

 

 
 
 
 
 
Thanks
 
 
Regards
Anurag Uxa
iWave systems = Technologies Pvt.=20 Ltd.
Bangalore
ph.6786243/5 extn :205
www.iwavesystems.com
 

DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation.

------=_NextPart_000_00E1_01C287E6.9A678AA0--