Subject: No PPPEXT meeting at London IETF

From: Karl Fox <[email-masked]>
Date: Wed, 13 Jun 2001 09:10:51 -0400

PPPEXT will not meet at the London IETF meeting.  I look forward to seeing 
you all this winter at Salt Lake City.

Karl

Karl Fox <[email-masked]>
Key fingerprint = 4159 B4AD 339D 4E2A 255F  9CC4 9DA9 CB4B B16D E2B1

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Jun 2001 17:30:50 +0300

>PPPEXT will not meet at the London IETF meeting.
>I look forward to seeing you all this winter at
>Salt Lake City.

Well, I was kind of expecting to discuss the new
EAP scheme, 3G AKA in London ... but perhaps we can
progress such work on the mailing list? Is it necessary
to meet to get something progress towards an RFC
status or to get WG work item status for something?

Any comments by the way from anybody on the below e-mail
and draft?

Jari
--------e-mail from June 4th-----------
Hello,

I'd like to announce that Henry Haverinen and myself have
produced an Internet-Draft that specifies how to run the
3G authentication scheme "AKA" within EAP:

  http://search.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-00.txt

The abstract states "This document specifies an Extensible
Authentication Protocol (EAP) mechanism for authentication
and session key distribution using the UMTS AKA authentication
mechanism. AKA is based on symmetric keys, and runs in a UMTS
Subscriber Identity Module, a smart card like device. AKA
provides also backward compatibility to GSM authentication,
making it possible to use EAP AKA for authenticating both GSM
and UMTS subscribers."

Comments on this draft would be wellcome. We'd also like to
hold a presentation on this draft in the London IETF.

Finally, we'd like this working group to consider this
draft for a Standards Track status, for the following
reasons:

- The draft is able to handle both GSM and UTMS
  authentication.
- The large number of existing and future GSM/UMTS
  clients (500-1000M) makes many applications likely.
- Possibilities for GSM-UMTS-WLAN-HIPERLAN interworking
  scenarios would benefit from an authentication scheme
  for which substantial deployment and billing infra-
  structure already exists.
- First 3GPP indications point to an interest
  to use this scheme as a part of their infrastructure.
(- The 3GPP2 has also adopted AKA though I can't say
  exactly in which manner they intend to use it, and
  whether the EAP AKA scheme would be useful to them.)

Jari

---

From: James Carlson <[email-masked]>
Date: Wed, 13 Jun 2001 10:59:22 -0400 (EDT)

> status or to get WG work item status for something?

No.  That's never necessary.  The only "official" IETF discussion is
done on the mailing list because not all participants are able to
travel to the IETF meeting sites.  The meetings are helpful if there
are unresolved issues in the drafts that need to be haggled out
face-to-face, but they're not definitive.

RFC 2418:

3.2. Session venue

   Each working group will determine the balance of email and face-to-
   face sessions that is appropriate for achieving its milestones.
   Electronic mail permits the widest participation; face-to-face
   meetings often permit better focus and therefore can be more
   efficient for reaching a consensus among a core of the working group
   participants.  In determining the balance, the WG must ensure that
   its process does not serve to exclude contribution by email-only
   participants.  Decisions reached during a face-to-face meeting about
   topics or issues which have not been discussed on the mailing list,
   or are significantly different from previously arrived mailing list
   consensus MUST be reviewed on the mailing list.

> Any comments by the way from anybody on the below e-mail

The operation of USIM-Authentication-Reject and
USIM-GSM-Authentication-Reject versus EAP Nak isn't clear to me.  What
do you expect the authenticator to do with these messages?  What does
the authenticatee do if it doesn't support this EAP extension at all?

I think the answer to the first question is that if the authenticator
receives either reject message, it performs the same function as if
the authenticatee had either sent Response message that didn't
validate correctly or had simply shut down the link.  If this is so,
then I don't see what the extra subtype does.

For the second question, I'd think that the authenticatee would send
EAP Nak.  How is that distinct from USIM-GSM-Authentication-Reject?

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 14 Jun 2001 00:05:13 -0700 (PDT)

> the authenticatee do if it doesn't support this EAP extension at all?

EAK Nak is sent to indicate that the peer does not support the required
authentication type. However, it isn't a general purpose error mechanism,
so it can't be used to say much more than that. In this particular usage,
distinct Reject message types are used, presumably to provide more detail
on the reasons why the peer cannot comply. I'm not sure that they provide
more information than a Nak does in this particular instance,
though. Given that the authenticator knows what it was trying to do, and
knows that the peer couldn't do it (a Nak tells you that), what more
information do these sub-types provide? 

I'd also note that we are seeing within multiple EAP methods the need to
communicate error conditions of various sorts. EAP itself does not
provide a way to do this; there is no Alert code. This is lame,
but probably not fixable at this point. However, I do think it
would be useful to develop an Alert sub-type message, with an embedded
error code, whose general format could be reused in multiple
methods, rather than utilizing different sub-types for each error
condition.

---

From: James Carlson <[email-masked]>
Date: Thu, 14 Jun 2001 07:20:08 -0400 (EDT)

> information do these sub-types provide? 

That's exactly the point.  If you can't authenticate through the
(presumably) pre-arranged method, then you may as well give up and try
some other method.  Something is quite broken.

> methods, rather than utilizing different sub-types for each error

Besides logging it to some diagnostic record in an implementation-
dependent manner, I'm not sure what the semantics of this EAP Alert
would be.  For existing PPP and EAP, I'd bury the disconnect reason in
the LCP Terminate-Request message instead.  (In fact, that's what I do
in my implementation.)

I'd prefer that we just obsolete 2284 and write a new draft that says
that Nak and Failure can carry diagnostic text.  That fixes the
problem at hand -- it allows both authenticator and authenticatee to
give some indication about what went wrong, should they choose to do
so.  Are there any implementations out there that *don't* accept Nak
or Failure messages with additional appended data?  Does anyone do a
strict comparison on the length and drop the message on the floor?
It seems to me that doing so would be an extremely poor design
decision (failing to be liberal in what's expected).

The interoperability of an Alert with existing EAP, on the other hand,
might be troublesome.  2284 doesn't give any hints about what to do
with unknown message codes.  There's no equivalent of "Code-Reject."
Unlike appending a text message, the result could be anything ...

(There are other flaws that could be fixed with a new draft.  For
example, what EAP Nak message do you send if you have *no* more
acceptable types left to suggest?)

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 14 Jun 2001 08:45:02 -0700 (PDT)

> so.  

Notification might also be used.

> Are there any implementations out there that *don't* accept Nak
> or Failure messages with additional appended data?  

Yes. Because Failure messages are not ACK'd you can't assume that the peer
will receive the message at all, let alone the appended data. So with RFC
2284 as it currently stands, adding data to a Success or Failure message
is probably a bad idea. 

Naks already can carry a data field, and are ACK'd, so this concern would
not apply here. 

> with unknown message codes.  

Another "issue" to add to the list in a revision discussion.  

> acceptable types left to suggest?)

I'm creating a list of outstanding issues for an EAP revision. I'll add
this one to the list. If you have others, please post them.

---

From: James Carlson <[email-masked]>
Date: Thu, 14 Jun 2001 12:26:41 -0400 (EDT)

> Notification might also be used.

That only really works from the authenticator side.  The authenticatee
can't use Notification.  If it did, that message would apply only if
there were mutual authentication, and then only to the separate
authentication conversation in the other direction.

> Yes.

If so, I think that's a sad state of affairs.  Postel's note in RFC
791 is really quite old now.

> Because Failure messages are not ACK'd you can't assume that the peer

True, of course, they're not acknowledged.  However, we're not talking
about something that necessarily *requires* acknowledgment.  We're
talking about some diagnostic information that would be nice to
deliver to the peer, but won't cause any undue harm if it isn't.  Of
course, any decent implementation would take pains to make sure that
the chance that this message is lost is fairly low.

> Naks already can carry a data field, and are ACK'd, so this concern would

No.  Naks are Response only.  There is no acknowledgment of a Nak.
The subsequent Request message (if any) doesn't acknowledge it.  As
written, there are acknowledgments from authenticatee to authenticator
only.  There are none in the reverse direction.

> this one to the list. If you have others, please post them. 

Some text about what the authenticator ought to do when the Nak hint
isn't acceptable might be good.  (Of course, this might just say that
the behavior is "implementation defined.")