From owner-ietf-ppp@merit.edu Fri Dec 21 11:29:50 2001 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 LAA25971 for ; Fri, 21 Dec 2001 11:29:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFA109127D; Fri, 21 Dec 2001 11:29:37 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B550A9127E; Fri, 21 Dec 2001 11:29:36 -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 A51569127D for ; Fri, 21 Dec 2001 11:29:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CC275DDDC; Fri, 21 Dec 2001 11:29:35 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from karl-s-laptop (dhcp93125084.columbus.rr.com [24.93.125.84]) by segue.merit.edu (Postfix) with ESMTP id 3EF9D5DDAC for ; Fri, 21 Dec 2001 11:29:31 -0500 (EST) Received: from [127.0.0.1] by karl-s-laptop (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Fri, 21 Dec 2001 11:28:39 -0500 Message-Id: <5.1.0.14.2.20011221105015.046445f0@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Dec 2001 11:28:30 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: 52nd IETF PPPEXT Meeting Minutes Cc: minutes@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3106468==_.ALT" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --=====================_3106468==_.ALT Content-Type: text/plain; charset="us-ascii" Thanks to Pat Calhoun for taking these minutes. Point-to-Point Protocol Extensions Working Group (PPPEXT) Tuesday, December 11 at 1700-1800 Chair: Karl Fox Attendance: 55 ======== EAP AKA Authentication draft-arkko-pppext-eap-aka-01.txt Jari Arkko, Jari Malinen This document describes the UMTS Authentication and Key Agreement used in 3G networks and based on symmetric crypto. It improves upon the old GSM authentication, includes mutual authentication and supports 128 bit keys. The main goal is for WLAN/UMTS interworking, such as for dual-mode terminals. SIMs that support AKA will soon reach 1 billion cards deployed. The extension defines the USIM challenge and response, which includes challenge information, sequence and authentication information. The client responds with the proper response via the USIM response. It includes optional subscriber identity privacy support, as well as mutual authentication and replay protection (via the sequence number). UMTS AKA includes a GSM compatible mode. It is up to the policies of the endpoints if they wish to run this mode. This draft minimizes the number of round trips, which is important in certain wireless technologies. There are two ways of optimizing, one of which is to allow the client to send an unsolicited EAP ID response, but this could break RFC2284 implementations. An alternative is for the client to send the ID request and attach the identity within the message. Then a challenge is issued by the NAS. A large base of SIM cards exist that can be used for EAP authentication, and the authors would like to see this document become a standards track working group document. Q: What is the standards state of AKA? A: AKA is an accepted standard in 3GPP, and a reference is provided in the Internet-Draft. Q: AKA is widely available, so this method could benefit that installed base. Minimizing the number of round trips is a good goal, and incorporating the identity in the request is a good thing, but you need to be prepared for the server to issue the request. So we cannot guarantee that optimization will occur, but it is fine as an option. A: Who can initiate to whom is an issue, since it's a peer to peer protocol, but sending a response without a request doesn't allow you to retransmit properly (RFC2284 states responses are not retransmitted). Q: Would it be possible to combine this draft with the GSM draft into one? Same question for the 3GPP2 draft. A: What would be the advantage? Fewer EAP documents? Q: Was EAP AKA mentioned to be widely implemented, or available? A: Currently the GSM is widely deployed, but AKA will be. The author knows of two implementations, but these are not in products. Q: Is this mechanism only useful when the backend server is an HRL, or can a RADIUS server support this as well? A: Yes. ======== IP Header Compression over PPP draft-koren-pppext-rfc2509bis-00.txt Tmima Koren This document describes a new IP header compression technique (IPHC) negotiated during IPCP (RFC 2509). The IP-Compression-Protocol is 61. The protocol supports sub-options. The first states that the initiator wishes to do RTP and UDP compression, as well as context state (RFC 2508). The next enhancement to RFC 2509 is draft-ietf-avt-crtp-enhance-03.txt, the main point of which is to allow repeating the update several times to add robustness. Another enhancement is to allow either only TCP or only non-TCP packet compression. The author is asking for this document to become a WG document, and since it is so simple perhaps a last call. ======== EAP-Shared Key Exchange (EAP-SKE): A Scheme for Authentication and Dynamic Key Exchange in 802.1X Networks draft-salgarelli-pppext-eap-ske-00.txt Luca Salgarelli EAP-SKE does mutual authentication of client and server based on crypto with strong pre-shared keys. It does authentication and session key derivation. SKE does not specify any particular ciphersuite. It is specifically designed to efficiently support roaming clients (H-AAA can be "distant from the local access network") and the client can use Mobile IP. Only 1 RTT from access network to the H-AAA is required to complete authentication and session key distribution. A minimal number of messages is exchanged between supplicant and authenticator. It supports evolution towards 1-pass authentication for Mobile-IP enabled clients. This scheme requires that the user has a security association with its H-AAA. The F-AAA (in a foreign network) shares an SA with the H-AAA and the AS-PAE (network access device) shares an SA with the F-AAA. The protocol defines an EAP message called the EAP-SKE-Request which includes a nonce, which is used by the mobile to generate the authentication information. The mobile includes the nonce and the authentication info in its EAP-SKE-Response, which it passes to the authentication server (H-AAA). The H-AAA includes a new nonce, which is then passed back to the mobile. This last nonce is used by the mobile and the NAS to generate the session key. This has the advantage that the session key is never passed over the air. It also has the advantage of only requiring a single round trip between the NAS and the H-AAA, and is secure. The draft mandates HMAC-MD5 to calculate the MAC. Prefix/Suffix MD5 is mandated to generate the PRF. Other MACs and PRFs are acceptable. This provides both secrecy and authenticity. The session key is guaranteed to be fresh, random and unique. Forward secrecy: compromising the session key does not compromise past or future keys, or the master shared secret. Efficiency: only 7 messages pass between the MN and NAS. There is only 1 RTT between the NAS and H-AAA. Q: Why suffix/prefix? The IESG has told all new MIP documents to only use HMAC-MD5. A: They will change Q: What about man in the middle attacks? A: Replays should be prevented because you have two nonces (N1, N2). Q: But N2 is generated by the local AAA, and can this be trusted? A: Yes, that is the assumption. Q: Does this scale? A: AAA has hierarchy, and with brokers it does scale. Q: How much trust do you want to have? The local AAA can pretty easily masquerade as the mobile. A: He is able to access the network as the user. Q: How can the home even know that this kind of attack is occurring? A: By keeping logs. Q: But this doesn't work very well. A: This is the only attack that we know of. The roaming agreement is the trust. Q: This is not a contractual problem, so fix it with security. Otherwise, MD5 is fine. Then CHAP is fine, right? A: No, because it is not mutual. ======== Extensible Authentication Protocol (EAP) draft-ietf-pppext-rfc2284bis-01.txt Bernard Aboba We are advancing EAP to IETF Draft Standard (including the required EAP implementation survey and interoperability testing). Interoperability issues are clarified within the spec. Support for multiple media types (PPP, 802.x and PIC (EAP over UDP) is also recognized. We'd like a more complete list, so if folks have other points, please send them to us. This is not EAP version 2. No changes will be added that break backward compatibility. This will not revise RADIUS, nor 802.1X. Interoperability: Does anybody have CIUG results of past EAP testing? Are there any plans for additional testing? There will be some interoperability testing for 802.1X in Las Vegas in May 2002. Survey results: We found 2 over PPP, 2 over IEEE 802.3 and one over 802.11. Many stated that they were not ready yet, so more info is forthcoming. We also think that there are some people that haven't received the survey. Some features were not implemented: OTP/Generic token card, Default retransmission timer of 6 seconds, Allowing for loss of EAP success and Failure packets via alternative indications. Display of notification to user and use of indicate invalid authentication attempt. Generic Token Card/OTP: These were moved into a new draft (removed from EAPbis). More areas may also be removed. Areas required clarification: EAP lower layer assumptions In RFC2284, it was assumed to be PPP and this was not a problem Doesn't assume reliability Doesn't assume ordered delivery Doesn't assume non-duplication of packet Success/Failure indication Meaning of success/failure? Alternative indication of success/failure (e.g. LCP terminate, many not exist in all lower layers) Mutual authentication PPP is a peer to peer protocol (implies that EAP auth can be done in either direction) RFC 2284bis does not state whether client can send EAP-Success /Failure to server Mutual authentication often necessary (mandatory to implement method (EAP-MD5) is a one-way method. EAP Method Negotiation NAK only allows one method to be returned (negotiation can be very lengthy) Can we allow multiple methods to be included in a NAK? (would this break existing implementations?) NAS Role in retransmissions EAP retransmission behavior and interactions with AAA Client never retransmits EAP-Response on its own NAS can retransmit doesn't take RTT into account Result : NAS can retransmit before it is assumed that EAP-Request has been lost and can send duplicate EAP-Responses). In RADIUS, NAS is responsible for retransmissions Next Steps: Clean up RFC2284bis Revise RADIUS extensions (RFC 2969) Create new EAP BCP document? ======== Protected Extensible Authentication Protocol (PEAP) draft-josefsson-pppext-eap-tls-eap-01.txt) Glen Zorn PEAP does have the cutest EAP method name. It includes mutual authentication and provides confidentiality and integrity of vulnerable credentials It protects against both active and passive attacks (eavesdropping and man-in-the-middle) and performs secure generation of session keys. It is compatible with the existing AA infrastructure and authentication protocols. It supports simple intra-subnet mobility via fast re-authentication (from across APs it can be relatively fast). It uses TLS to - authenticate the network infrastructure (TLS handshake protocol packets) - Protect user credentials in transit (TLS record protocol packets) - Generate cryptographic keying material (TLS PRF) It uses the same encapsulation as EAP-TLS, but continues after the handshake, using the TLS record protocol. It encapsulates EAP in TLS and can contain any type of packet, such as OTP, MD5 and GSS (particularly Kerberos). It requires two phases: - Phase 1: has public key authentication of network infrastructure, and creation of secure association - Phase 2: performs user authentication (using the term user loosely). Phase 1 requires 4 round trips, but the number is lower upon re-authentication. Phase 2 requires 2.5 round trips. Q: If you had an unsuccessful authentication, a re-authentication could use data in the SSL cache. A: We are not doing phase 2. Q: Unless you could flush the data in the SSL cache, this could be a problem. A: The document states that you have to get rid of that key Q: Do you only cache when Phase 2 is successful? A: Yes Q: Ifyou have been authenticated once, and then you move into a network that requires a more secure authentication, do you pass phase one? A: It depends, there is a more interesting question than that. The reason why MIM attacks were brought up earlier is that PEAP is also subject to this problem. However, since RADIUS itself can replay, then this is a problem. Q: I don't believe there is a problem. There is authentication between the PEAP server and the client. There is another problem that the TTLS addresses, which is when you do the session resumption, if you just rely on the shared master secret, you don't know what to send back. The server that does the TLS caches response, and sends it back. A: The obvious way is to send back the TLS master key, which is bad. But there are other ways of solving this problem easily. We are not sure that we need to solve this problem, though, because CHAP works fine here. Is this important? But since we already live with it, do we care? ======== EAP SIM Authentication draft-haverinen-pppext-eap-sim-02.txt Jari Malinen EAP type for GSM authentication using the subscriber identity module. Can be implemented with an authentication gateway--no other changes are required to FSM/GPRS network. GSM operator roaming and the large deployed base of SIM cards can be used. EAP/SIM enhancements to GSM 03.20 authentication: - A terminate generated nonce is used in key derivation - Challenges accompanied with a MAC for mutual authentication - Several challenges are used to generate longer keys These enhancements are different between EAP/SIM and EAP/AKA GSM modes (EAP/SIM uses one round trip more than EAP/AKA GSM mode). Main usage scenario: wireless LAN access authentication (other EAP application are possible too). Changes since -01: new message format, updated key derivation and subscriber identity privacy with pseudonyms. We'd like this draft to become a standards track item. Q: There are similarities between the three documents AKA, AKA/GSM and this one. All of these are useful and necessary, but could we perhaps have a single EAP method? The message flows may be a little different, so perhaps roll all GSM into a single draft, and the native AKA into a separate draft. A: Ok. ======== EAP Tunneled TLS Authentication Protocol (EAP-TTLS) draft-ietf-pppext-eap-ttls-00.txt Paul Funk This describes tunneled TLS: user credentials encapsulated in TLS. TTLS tunnels not only EAP but RADIUS, CHAP, MS-CHAP, etc., even PAP securely. It solves problems of both key material and key usage, and it adds a lot of flexibility to vendor network AAA architectures. --=====================_3106468==_.ALT Content-Type: text/html; charset="us-ascii" Thanks to Pat Calhoun <pcalhoun@bstormnetworks.com> for taking these minutes.

Point-to-Point Protocol Extensions Working Group (PPPEXT)
Tuesday, December 11 at 1700-1800
Chair:  Karl Fox <karlfox@columbus.rr.com>
Attendance: 55
========
EAP AKA Authentication
draft-arkko-pppext-eap-aka-01.txt
Jari Arkko, Jari Malinen

This document describes the UMTS Authentication and Key Agreement used in 3G
networks and based on symmetric crypto. It improves upon the old GSM
authentication, includes mutual authentication and supports 128 bit keys.
The main goal is for WLAN/UMTS interworking, such as for dual-mode
terminals. SIMs that support AKA will soon reach 1 billion cards deployed.

The extension defines the USIM challenge and response, which includes
challenge information, sequence and authentication information. The client
responds with the proper response via the USIM response.

It includes optional subscriber identity privacy support, as well as mutual
authentication and replay protection (via the sequence number).

UMTS AKA includes a GSM compatible mode.   It is up to the policies of the
endpoints if they wish to run this mode.

This draft minimizes the number of round trips, which is important in
certain wireless technologies. There are two ways of optimizing, one of
which is to allow the client to send an unsolicited EAP ID response, but
this could break RFC2284 implementations. An alternative is for the client
to send the ID request and attach the identity within the message. Then a
challenge is issued by the NAS.

A large base of SIM cards exist that can be used for EAP authentication, and
the authors would like to see this document become a standards track working
group document.

Q: What is the standards state of AKA?
A: AKA is an accepted standard in 3GPP, and a reference is provided in the
Internet-Draft.

Q: AKA is widely available, so this method could benefit that installed
base. Minimizing the number of round trips is a good goal, and incorporating
the identity in the request is a good thing, but you need to be prepared for
the server to issue the request. So we cannot guarantee that optimization
will occur, but it is fine as an option.
A: Who can initiate to whom is an issue, since it's a peer to peer protocol,
but sending a response without a request doesn't allow you to retransmit
properly (RFC2284 states responses are not retransmitted).

Q: Would it be possible to combine this draft with the GSM draft into one?
Same question for the 3GPP2 draft.
A: What would be the advantage? Fewer EAP documents?

Q: Was EAP AKA mentioned to be widely implemented, or available?
A: Currently the GSM is widely deployed, but AKA will be. The author knows
of two implementations, but these are not in products.

Q: Is this mechanism only useful when the backend server is an HRL, or can a
RADIUS server support this as well?
A: Yes.

========
IP Header Compression over PPP
draft-koren-pppext-rfc2509bis-00.txt
Tmima Koren

This document describes a new IP header compression technique (IPHC)
negotiated during IPCP (RFC 2509). The IP-Compression-Protocol is 61. The
protocol supports sub-options. The first states that the initiator wishes to
do RTP and UDP compression, as well as context state (RFC 2508).

The next enhancement to RFC 2509 is draft-ietf-avt-crtp-enhance-03.txt, the
main point of which is to allow repeating the update several times to add
robustness. Another enhancement is to allow either only TCP or only non-TCP
packet compression.

The author is asking for this document to become a WG document, and since it
is so simple perhaps a last call.

========
EAP-Shared Key Exchange (EAP-SKE): A Scheme for Authentication and Dynamic
Key Exchange in 802.1X Networks
draft-salgarelli-pppext-eap-ske-00.txt
Luca Salgarelli

EAP-SKE does mutual authentication of client and server based on crypto with
strong pre-shared keys.  It does authentication and session key derivation.
SKE does not specify any particular ciphersuite.  It is specifically
designed to efficiently support roaming clients (H-AAA can be "distant from
the local access network") and the client can use Mobile IP.

Only 1 RTT from access network to the H-AAA is required to complete
authentication and session key distribution.  A minimal number of messages
is exchanged between supplicant and authenticator.  It supports evolution
towards 1-pass authentication for Mobile-IP enabled clients.

This scheme requires that the user has a security association with its
H-AAA. The F-AAA (in a foreign network) shares an SA with the H-AAA and the
AS-PAE (network access device) shares an SA with the F-AAA.

The protocol defines an EAP message called the EAP-SKE-Request which
includes a nonce, which is used by the mobile to generate the authentication
information. The mobile includes the nonce and the authentication info in
its EAP-SKE-Response, which it passes to the authentication server (H-AAA).
The H-AAA includes a new nonce, which is then passed back to the mobile.
This last nonce is used by the mobile and the NAS to generate the session
key. This has the advantage that the session key is never passed over the
air.  It also has the advantage of only requiring a single round trip
between the NAS and the H-AAA, and is secure.

The draft mandates HMAC-MD5 to calculate the MAC. Prefix/Suffix MD5 is
mandated to generate the PRF. Other MACs and PRFs are acceptable.

This provides both secrecy and authenticity. The session key is guaranteed
to be fresh, random and unique.  Forward secrecy: compromising the session
key does not compromise past or future keys, or the master shared secret.
Efficiency: only 7 messages pass between the MN and NAS.  There is only 1
RTT between the NAS and H-AAA.

Q: Why suffix/prefix? The IESG has told all new MIP documents to only use
HMAC-MD5.
A: They will change

Q: What about man in the middle attacks?
A: Replays should be prevented because you have two nonces (N1, N2).

Q: But N2 is generated by the local AAA, and can this be trusted?
A: Yes, that is the assumption.

Q: Does this scale?
A: AAA has hierarchy, and with brokers it does scale.

Q: How much trust do you want to have? The local AAA can pretty easily
masquerade as the mobile.
A: He is able to access the network as the user.

Q: How can the home even know that this kind of attack is occurring?
A: By keeping logs.

Q: But this doesn't work very well.
A: This is the only attack that we know of. The roaming agreement is the
trust.

Q: This is not a contractual problem, so fix it with security. Otherwise,
MD5 is fine. Then CHAP is fine, right?
A: No, because it is not mutual.

========
Extensible Authentication Protocol (EAP)
draft-ietf-pppext-rfc2284bis-01.txt
Bernard Aboba

We are advancing EAP to IETF Draft Standard (including the required EAP
implementation survey and interoperability testing). Interoperability issues
are clarified within the spec. Support for multiple media types (PPP, 802.x
and PIC (EAP over UDP) is also recognized. We'd like a more complete list,
so if folks have other points, please send them to us.

This is not EAP version 2. No changes will be added that break backward
compatibility. This will not revise RADIUS, nor 802.1X.

Interoperability:  Does anybody have CIUG results of past EAP testing?  Are
there any plans for additional testing? There will be some interoperability
testing for 802.1X in Las Vegas in May 2002.

Survey results: We found 2 over PPP, 2 over IEEE 802.3 and one over 802.11.
Many stated that they were not ready yet, so more info is forthcoming. We
also think that there are some people that haven't received the survey.

Some features were not implemented: OTP/Generic token card, Default
retransmission timer of 6 seconds, Allowing for loss of EAP success and
Failure packets via alternative indications. Display of notification to user
and use of indicate invalid authentication attempt.

Generic Token Card/OTP: These were moved into a new draft (removed from
EAPbis). More areas may also be removed.

Areas required clarification:
        EAP lower layer assumptions
                In RFC2284, it was assumed to be PPP and this was not a problem
                Doesn't assume reliability
                Doesn't assume ordered delivery
                Doesn't assume non-duplication of packet
Success/Failure indication
        Meaning of success/failure?
        Alternative indication of success/failure (e.g. LCP terminate, many not
                exist in all lower layers)
Mutual authentication
        PPP is a peer to peer protocol (implies that EAP auth can be done in
                either direction)
        RFC 2284bis does not state whether client can send EAP-Success
                /Failure to server
        Mutual authentication often necessary (mandatory to implement method
                (EAP-MD5) is a one-way method.
EAP Method Negotiation
        NAK only allows one method to be returned (negotiation can be very
                lengthy)
Can we allow multiple methods to be included in a NAK? (would this
break existing implementations?)

        NAS Role in retransmissions
                EAP retransmission behavior and interactions with AAA
                Client never retransmits EAP-Response on its own
                NAS can retransmit doesn't take RTT into account
                Result : NAS can retransmit before it is assumed that
                        EAP-Request has been lost and can send duplicate
                        EAP-Responses).
                In RADIUS, NAS is responsible for retransmissions

Next Steps:
        Clean up RFC2284bis
        Revise RADIUS extensions (RFC 2969)
        Create new EAP BCP document?

========
Protected Extensible Authentication Protocol (PEAP)
draft-josefsson-pppext-eap-tls-eap-01.txt)
Glen Zorn

PEAP does have the cutest EAP method name. It includes mutual authentication
and provides confidentiality and integrity of vulnerable credentials

It protects against both active and passive attacks (eavesdropping and
man-in-the-middle) and performs secure generation of session keys.

It is compatible with the existing AA infrastructure and authentication
protocols. It supports simple intra-subnet mobility via fast
re-authentication (from across APs it can be relatively fast).

It uses TLS to
-       authenticate the network infrastructure (TLS handshake protocol
        packets)
-       Protect user credentials in transit (TLS record protocol packets)
-       Generate cryptographic keying material (TLS PRF)

It uses the same encapsulation as EAP-TLS, but continues after the
handshake, using the TLS record protocol. It encapsulates EAP in TLS and can
contain any type of packet, such as OTP, MD5 and GSS (particularly Kerberos).

It requires two phases:
-       Phase 1: has public key authentication of network infrastructure,
        and creation of secure association
-       Phase 2: performs user authentication (using the term user loosely).

Phase 1 requires 4 round trips, but the number is lower upon
re-authentication. Phase 2 requires 2.5 round trips.

Q: If you had an unsuccessful authentication, a re-authentication could use
data in the SSL cache.
A: We are not doing phase 2.

Q: Unless you could flush the data in the SSL cache, this could be a problem.
A: The document states that you have to get rid of that key

Q: Do you only cache when Phase 2 is successful?
A: Yes

Q: Ifyou have been authenticated once, and then you move into a network that
requires a more secure authentication, do you pass phase one?
A: It depends, there is a more interesting question than that. The reason
why MIM attacks were brought up earlier is that PEAP is also subject to
this problem. However, since RADIUS itself can replay, then this is a problem.

Q: I don't believe there is a problem. There is authentication between the
PEAP server and the client. There is another problem that the TTLS
addresses, which is when you do the session resumption, if you just rely on
the shared master secret, you don't know what to send back. The server that
does the TLS caches response, and sends it back.
A: The obvious way is to send back the TLS master key, which is bad. But
there are other ways of solving this problem easily. We are not sure that we
need to solve this problem, though, because CHAP works fine here. Is this
important? But since we already live with it, do we care?

========
EAP SIM Authentication
draft-haverinen-pppext-eap-sim-02.txt
Jari Malinen

EAP type for GSM authentication using the subscriber identity module.

Can be implemented with an authentication gateway--no other changes are
required to FSM/GPRS network.

GSM operator roaming and the large deployed base of SIM cards can be used.

EAP/SIM enhancements to GSM 03.20 authentication:
-       A terminate generated nonce is used in key derivation
-       Challenges accompanied with a MAC for mutual authentication
-       Several challenges are used to generate longer keys
These enhancements are different between EAP/SIM and EAP/AKA GSM modes
(EAP/SIM uses one round trip more than EAP/AKA GSM mode).

Main usage scenario: wireless LAN access authentication (other EAP
application are possible too).

Changes since -01: new message format, updated key derivation and subscriber
identity privacy with pseudonyms.

We'd like this draft to become a standards track item.

Q: There are similarities between the three documents AKA, AKA/GSM and this
one. All of these are useful and necessary, but could we perhaps have a
single EAP method? The message flows may be a little different, so perhaps
roll all GSM into a single draft, and the native AKA into a separate draft.
A: Ok.

========
EAP Tunneled TLS Authentication Protocol (EAP-TTLS)
draft-ietf-pppext-eap-ttls-00.txt
Paul Funk

This describes tunneled TLS: user credentials encapsulated in TLS.

TTLS tunnels not only EAP but RADIUS, CHAP, MS-CHAP, etc., even PAP securely.

It solves problems of both key material and key usage, and it adds a lot of
flexibility to vendor network AAA architectures. --=====================_3106468==_.ALT--