[RFC sim-authenticate PATCH 0/3]

[RFC sim-authenticate PATCH 0/3]

[Pekka.Pessi]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

Hi all,

Here is first proposal for SIM authentication API.  The API provides
access to ordinary SIM authentication methods.  The first two methods
are intended for implementing EAP authentication using cellular
authentication mechanisms, the third one for implementing AKA
authentication algorithm used with IMS.

There can be special EAP application implementing EAP protocol and using
secrets and authentication methods separate from cellular authentication
on SIM card; it is not handled here.

I have no clear idea how the GBA authentication should be used, I'll add
that later.

--Pekka

[RFC sim-authenticate PATCH 1/3] TODO: add SIM authentication

[Pekka.Pessi]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

From: Pekka Pessi <Pekka.Pessi@nokia.com>

---
 TODO |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/TODO b/TODO
index 12f313b..8cd5ada 100644
--- a/TODO
+++ b/TODO
@@ -105,6 +105,12 @@ SIM / SIM File system
   Complexity: C1
   Owner: Marit Henriksen <marit.henriksen@stericsson.com>
 
+- Support SIM authentication: EAP-SIM, EAP-AKA, IMS-AKA and GBA.
+
+  Priority: Medium
+  Complexity: C2
+  Owner: Pekka Pessi <pekka.pessi@nokia.com>
+
 Modem Emulator
 ==============
 
-- 
1.7.1

[RFC sim-authenticate PATCH 2/3] Added doc/sim-authentication-api.txt.

[Pekka.Pessi]

[-- Attachment #1: Type: text/plain, Size: 2657 bytes --]

From: Pekka Pessi <Pekka.Pessi@nokia.com>

The EAP applications on SIM should be handled separately. The
EapSimAuthenticate and EapAkaAuthenticate do not require a special EAP
application on SIM, but they use ordinary cellular authentication.
---
 doc/sim-authentication-api.txt |   66 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 66 insertions(+), 0 deletions(-)
 create mode 100644 doc/sim-authentication-api.txt

diff --git a/doc/sim-authentication-api.txt b/doc/sim-authentication-api.txt
new file mode 100644
index 0000000..9a033bf
--- /dev/null
+++ b/doc/sim-authentication-api.txt
@@ -0,0 +1,66 @@
+SimAuthentication hierarchy
+===========================
+
+Service		org.ofono
+Interface	org.ofono.SimAuthentication
+Object path	[variable prefix]/{modem0,modem1,...}
+
+Methods		byte{array} EapSimAuthenticate(array{byte} rand)
+
+			Executes the SIM authentication algorithm for
+			RFC 4186 EAP SIM authentication method.
+
+			The input parameter is RAND, a 16-byte array.
+			In case of successful authentication operation
+			the SRES parameter is returned as a 4-byte array.
+
+			Possible Errors: [service].Error.InvalidArguments
+				 	 [service].Error.NotImplemented
+
+		dict EapAkaAuthenticate(array{byte} rand, array{byte} autn)
+
+			Executes the AKA authentication algorithm for
+			RFC 4187 EAP AKA authentication method.
+
+			All the parameters and keys are 16-byte arrays.
+
+			In case of successful authentication the
+			returned dictionary contains following items:
+
+			byte{array} "RES" - AKA RES parameter
+
+			byte{array} "CK" - AKA Ciphering key
+
+			byte{array} "IK" - AKA Integrity key
+
+			In case of unsuccessful authentication the
+			returned dictionary contain following item:
+
+			byte{array} "AUTS" - AKA AUTS parameter
+
+			Possible Errors: [service].Error.InvalidArguments
+				 	 [service].Error.NotImplemented
+
+		dict ImsAkaAuthenticate(array{byte} rand, array{byte} autn)
+
+			Executes the AKA authentication algorithm in
+			ISIM or, if ISIM is not available, in USIM.
+
+			All the parameters and keys are 16-byte arrays.
+
+			In case of successful authentication the
+			returned dictionary contains following items:
+
+			byte{array} "RES" - AKA RES parameter
+
+			byte{array} "CK" - AKA Ciphering key
+
+			byte{array} "IK" - AKA Integrity key
+
+			In case of unsuccessful authentication the
+			returned dictionary contain following item:
+
+			byte{array} "AUTS" - AKA AUTS parameter
+
+			Possible Errors: [service].Error.InvalidArguments
+				 	 [service].Error.NotImplemented
-- 
1.7.1

[RFC sim-authenticate PATCH 3/3] Include doc/sim-authentication-api.txt in dist.

[Pekka.Pessi]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

From: Pekka Pessi <Pekka.Pessi@nokia.com>

---
 Makefile.am |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 8a8555d..1f79fff 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -367,6 +367,7 @@ doc_files = doc/overview.txt doc/ofono-paper.txt doc/release-faq.txt \
 			doc/message-api.txt doc/message-waiting-api.txt \
 			doc/phonebook-api.txt doc/radio-settings-api.txt \
 			doc/sim-api.txt doc/stk-api.txt \
+			doc/sim-authentication-api.txt \
 			doc/audio-settings-api.txt doc/text-telephony-api.txt \
 			doc/calypso-modem.txt
 
-- 
1.7.1

Re: [RFC sim-authenticate PATCH 2/3] Added doc/sim-authentication-api.txt.

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

Hi Pekka,

> The EAP applications on SIM should be handled separately. The
> EapSimAuthenticate and EapAkaAuthenticate do not require a special EAP
> application on SIM, but they use ordinary cellular authentication.
> ---
>  doc/sim-authentication-api.txt |   66 ++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 66 insertions(+), 0 deletions(-)
>  create mode 100644 doc/sim-authentication-api.txt
> 
> diff --git a/doc/sim-authentication-api.txt b/doc/sim-authentication-api.txt
> new file mode 100644
> index 0000000..9a033bf
> --- /dev/null
> +++ b/doc/sim-authentication-api.txt
> @@ -0,0 +1,66 @@
> +SimAuthentication hierarchy
> +===========================
> +
> +Service		org.ofono
> +Interface	org.ofono.SimAuthentication
> +Object path	[variable prefix]/{modem0,modem1,...}
> +
> +Methods		byte{array} EapSimAuthenticate(array{byte} rand)
> +
> +			Executes the SIM authentication algorithm for
> +			RFC 4186 EAP SIM authentication method.
> +
> +			The input parameter is RAND, a 16-byte array.
> +			In case of successful authentication operation
> +			the SRES parameter is returned as a 4-byte array.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +				 	 [service].Error.NotImplemented
> +
> +		dict EapAkaAuthenticate(array{byte} rand, array{byte} autn)

so I would rather have an interface where you can discover the supported
authentication applications on the SIM card and then have one interface
to execute them.

The application using this interface needs somehow to know what methods
are available and not do some try and error execution.

The EAP SIM is a subset of any proper AKA mechanism, but that should be
fine as well. Just having an empty AUTN array seems fine to me.

Regards

Marcel

Re: [RFC sim-authenticate PATCH 2/3] Added doc/sim-authentication-api.txt.

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]

Hi Marcel,

2011/1/3 Marcel Holtmann <marcel@holtmann.org>:
>> The EAP applications on SIM should be handled separately. The
>> EapSimAuthenticate and EapAkaAuthenticate do not require a special EAP
>> application on SIM, but they use ordinary cellular authentication.
>> ---
>>  doc/sim-authentication-api.txt |   66 ++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 66 insertions(+), 0 deletions(-)
>>  create mode 100644 doc/sim-authentication-api.txt
>>
>> diff --git a/doc/sim-authentication-api.txt b/doc/sim-authentication-api.txt
>> new file mode 100644
>> index 0000000..9a033bf
>> --- /dev/null
>> +++ b/doc/sim-authentication-api.txt
>> @@ -0,0 +1,66 @@
>> +SimAuthentication hierarchy
>> +===========================
>> +
>> +Service              org.ofono
>> +Interface    org.ofono.SimAuthentication
>> +Object path  [variable prefix]/{modem0,modem1,...}
>> +
>> +Methods              byte{array} EapSimAuthenticate(array{byte} rand)
>> +
>> +                     Executes the SIM authentication algorithm for
>> +                     RFC 4186 EAP SIM authentication method.
>> +
>> +                     The input parameter is RAND, a 16-byte array.
>> +                     In case of successful authentication operation
>> +                     the SRES parameter is returned as a 4-byte array.
>> +
>> +                     Possible Errors: [service].Error.InvalidArguments
>> +                                      [service].Error.NotImplemented
>> +
>> +             dict EapAkaAuthenticate(array{byte} rand, array{byte} autn)
>
> so I would rather have an interface where you can discover the supported
> authentication applications on the SIM card and then have one interface
> to execute them.

> The application using this interface needs somehow to know what methods
> are available and not do some try and error execution.

Do you have something like this in your mind?

Methods		dict Authenticate(string appl, array{byte} RAND, array{byte} AUTN)

			In case of successful SIM authentication the
			returned dictionary contains following item:
			
			byte{array} "SRES" - SRES parameter

			In case of successful AKA authentication the
			returned dictionary contains following items:

			byte{array} "RES" - AKA RES parameter

			byte{array} "CK" - AKA Ciphering key

			byte{array} "IK" - AKA Integrity key

			In case of unsuccessful authentication the
			returned dictionary contain following item:

			byte{array} "AUTS" - AKA AUTS parameter
						
			Possible Errors: [service].Error.InvalidArguments
				 	 [service].Error.NotImplemented

Properties	array{string} Applications [readwrite]

			Contains the list of supported authentication
			applications. The possible values are:
				 "EAP-SIM" - GSM SIM authentication for EAP
				 "EAP-AKA" - AKA authentication for EAP
				 "IMS-AKA" - AKA authentication for IMS
				 "GBA" - GBA authentication

> The EAP SIM is a subset of any proper AKA mechanism, but that should be
> fine as well. Just having an empty AUTN array seems fine to me.

I'll see how GBA will fit to the architecture. According to the ISI
modem spec it might be straightforward.

-- 
Pekka.Pessi mail at nokia.com

Re: [RFC sim-authenticate PATCH 2/3] Added doc/sim-authentication-api.txt.

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3944 bytes --]

Hi Pekka,

> >> The EAP applications on SIM should be handled separately. The
> >> EapSimAuthenticate and EapAkaAuthenticate do not require a special EAP
> >> application on SIM, but they use ordinary cellular authentication.
> >> ---
> >>  doc/sim-authentication-api.txt |   66 ++++++++++++++++++++++++++++++++++++++++
> >>  1 files changed, 66 insertions(+), 0 deletions(-)
> >>  create mode 100644 doc/sim-authentication-api.txt
> >>
> >> diff --git a/doc/sim-authentication-api.txt b/doc/sim-authentication-api.txt
> >> new file mode 100644
> >> index 0000000..9a033bf
> >> --- /dev/null
> >> +++ b/doc/sim-authentication-api.txt
> >> @@ -0,0 +1,66 @@
> >> +SimAuthentication hierarchy
> >> +===========================
> >> +
> >> +Service              org.ofono
> >> +Interface    org.ofono.SimAuthentication
> >> +Object path  [variable prefix]/{modem0,modem1,...}
> >> +
> >> +Methods              byte{array} EapSimAuthenticate(array{byte} rand)
> >> +
> >> +                     Executes the SIM authentication algorithm for
> >> +                     RFC 4186 EAP SIM authentication method.
> >> +
> >> +                     The input parameter is RAND, a 16-byte array.
> >> +                     In case of successful authentication operation
> >> +                     the SRES parameter is returned as a 4-byte array.
> >> +
> >> +                     Possible Errors: [service].Error.InvalidArguments
> >> +                                      [service].Error.NotImplemented
> >> +
> >> +             dict EapAkaAuthenticate(array{byte} rand, array{byte} autn)
> >
> > so I would rather have an interface where you can discover the supported
> > authentication applications on the SIM card and then have one interface
> > to execute them.
> 
> > The application using this interface needs somehow to know what methods
> > are available and not do some try and error execution.
> 
> Do you have something like this in your mind?
> 
> Methods		dict Authenticate(string appl, array{byte} RAND, array{byte} AUTN)
> 
> 			In case of successful SIM authentication the
> 			returned dictionary contains following item:
> 			
> 			byte{array} "SRES" - SRES parameter
> 
> 			In case of successful AKA authentication the
> 			returned dictionary contains following items:
> 
> 			byte{array} "RES" - AKA RES parameter
> 
> 			byte{array} "CK" - AKA Ciphering key
> 
> 			byte{array} "IK" - AKA Integrity key
> 
> 			In case of unsuccessful authentication the
> 			returned dictionary contain following item:
> 
> 			byte{array} "AUTS" - AKA AUTS parameter
> 						
> 			Possible Errors: [service].Error.InvalidArguments
> 				 	 [service].Error.NotImplemented
> 
> Properties	array{string} Applications [readwrite]
> 
> 			Contains the list of supported authentication
> 			applications. The possible values are:
> 				 "EAP-SIM" - GSM SIM authentication for EAP
> 				 "EAP-AKA" - AKA authentication for EAP
> 				 "IMS-AKA" - AKA authentication for IMS
> 				 "GBA" - GBA authentication

yep, that is similar to what I was thinking about. Andrew is currently
looking on how to do SIM application discovery. So I like to get his
input on this as well.

On AT command modems, we are pretty much tight into SIM application
discover and execution of authentication methods. At least when reading
the specification. I have not yet tested this since right now we are not
even bothering with SIM application details inside oFono at all.

For WISPr 2.0 and 802.1x we will need to make this work as well.

> > The EAP SIM is a subset of any proper AKA mechanism, but that should be
> > fine as well. Just having an empty AUTN array seems fine to me.
> 
> I'll see how GBA will fit to the architecture. According to the ISI
> modem spec it might be straightforward.

Is there a public specification for GBA by any chance?

Regards

Marcel

Re: [RFC sim-authenticate PATCH 2/3] Added doc/sim-authentication-api.txt.

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Hi Marcel,

2011/1/3 Marcel Holtmann <marcel@holtmann.org>:
> yep, that is similar to what I was thinking about.

I'll update the proposal.

> Andrew is currently
> looking on how to do SIM application discovery. So I like to get his
> input on this as well.

The AT+CUAD looks straightforward enough. Unfortunately I've yet to
see a modem implementing AT+CUAD.

> On AT command modems, we are pretty much tight into SIM application
> discover and execution of authentication methods. At least when reading
> the specification. I have not yet tested this since right now we are not
> even bothering with SIM application details inside oFono at all.
>
> For WISPr 2.0 and 802.1x we will need to make this work as well.
>
>> > The EAP SIM is a subset of any proper AKA mechanism, but that should be
>> > fine as well. Just having an empty AUTN array seems fine to me.
>>
>> I'll see how GBA will fit to the architecture. According to the ISI
>> modem spec it might be straightforward.
>
> Is there a public specification for GBA by any chance?

33.220 is specifies the algorithm and 24.109 contains the protocol.
I'd recommend starting from the examples in 24.109, they are most
easiest to digest.

-- 
Pekka.Pessi mail at nokia.com

Re: [RFC sim-authenticate PATCH 2/3] Added doc/sim-authentication-api.txt.

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Hi Pekka,

> > Andrew is currently
> > looking on how to do SIM application discovery. So I like to get his
> > input on this as well.
> 
> The AT+CUAD looks straightforward enough. Unfortunately I've yet to
> see a modem implementing AT+CUAD.

the MBM F35xx does support this. At least when I quickly check while we
were in Paris. So I assume all MBM hardware should support it.

Regards

Marcel