Subject: 52nd IETF PPPEXT Meeting Minutes

From: Karl Fox <[email-masked]>
Date: Fri, 21 Dec 2001 11:28:30 -0500

Thanks to Pat Calhoun <[email-masked]> for taking these minutes.

Point-to-Point Protocol Extensions Working Group (PPPEXT)
Tuesday, December 11 at 1700-1800
Chair:  Karl Fox <[email-masked]>
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.