Subject: RE: [eap] draft-urien-eap-smartcard-03.txt

From: "Wouter Habraken" <[email-masked]>
Date: Mon, 22 Dec 2003 14:41:37 -0600

My comments below:

> Here are some questions about draft-urien-eap-smartcard-03.txt.
> 
> The subscriber profile is a service that can be used to 
> retrieve the EAP 
> types that the smart card implements, right? I suppose the 
> supplicant software can easily enumerate the all the EAP 
> methods that are available 
> beforehand. But I find it confusing that the draft talks 
> about identity selection 
> rather than EAP type selection. Shouldn't the supplicant 
> software select the active EAP method rather than an identity? 

There seems to be a misunderstanding about the role for the smart card.
With EAP-SMARTCARD the smart card holds the user identities and
credentials as well as the applets executing specific EAP methods. The
EAP "switch" is on the smart card. The identity is controlled by the
smart card and the EAP type flows from the choice of the identity and
the associated credentials. The selection of the preferred identity
establishes the authentication context for the card, but doesn't control
the identity.

> Maybe the subscriber profile could contain a short description of 
> the EAP method so that could be shown by the supplicant UI.
> 
The identity profile does already include the associated EAP method.
However it is unclear to me why this would be shown to the user.

> Have you considered EAP method negotiation in cases when
> some methods are implemented by the smart card and others by 
> supplicant software? I think this topic deserves some 
> discussion in this draft

Agreed, it is important. The focus of EAP-SMARTCARD has been on
providing a self contained EAP functionality. However, integrating the
EAP-SMARTCARD into a software EAP stack is important. Such an EAP stack
can call EAP-SMARTCARD, or can access the EAP methods directly. For
example, the software could access TLS via CAPI-CSP, SIM via EAP-SIM,
and WLAN-SIM via a WLAN-SIM compatible handler. Already there are
processes for identifying which methods are available on a card. The
WLAN smart card consortium is planning to publish a "handler"
specification to make this process easier (initially for WLAN-SIM). This
spec will also provide a default negotiation process to ensure card
interoperability.

> 
> If the supplicant first tries a software EAP method, and 
> later receives 
> an EAP request of some other type, the software could forward 
> the EAP request to the smart card. In this case, does the 
> terminal first need to cycle the identities to find the 
> correct EAP type, or can the EAP packet be directly forwarded 
> to the card?

It can be directly forwarded to the card. EAP-SMARTCARD makes the
association.

> 
> If the smart card method is not the first method to try 
> during EAP method negotiation, then there might not be an EAP 
> identity round at all, so the smart card authentication 
> should start directly with an EAP request other than 
> identity. So it should be possible to by-pass the identity 
> services. Or does the supplicant software need to fake an EAP 
> identity request and then ignore the response in order 
> to get the smart card's state initialized?

No, the process can start with any EAP request. No identity calls are
needed, and in fact would reset the smart card EAP state machine. If the
EAP Stack is handling method negotiation in this way though, it would
presumably call the EAP methods directly as described above.

- Wouter

Wouter Habraken
[email-masked]
Tel: 512 380 0765
Mob: 512 698 9341

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap