Strawman -10/EMSK deletion requirement?

Joe,
 

> -----Original Message-----
> From: Salowey, Joe [mailto:jsaloweycisco.com] 
> Sent: Friday, March 10, 2006 12:16 AM
> To: Avi Lior; Narayanan, Vidya; Jari Arkko
> Cc: eapfrascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
> 
>  
> 
> > -----Original Message-----
> > From: Avi Lior [mailto:avibridgewatersystems.com]
> > Sent: Thursday, March 09, 2006 9:03 PM
> > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko
> > Cc: eapfrascone.com
> > Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
> > 
> > Joe and All,
> > 
> > I totally agree with Joe.
> > 
> > AAA is a protocol that transports and cant realy
cache 
> anything in the 
> > case of RADIUS which is stateless.
> > 
> > So any caching has to be outside AAA or with AAA
(but 
> Diameter only). 
> 
> [Joe] I think a AAA server is typically composed of
several 
> components.
> One of these can be a key holder.  I don't see why you

> couldn't define new functionality in RADIUS to
interact with 
> the key holder (other than the fact that it seems to be

> difficult to define anything new in RADIUS). 

[Avi]  Aboslutely correct on all fronts .  A AAA
server can have
EAP-AS (authetncation server) and a key holder/key
generator.  So I
guess ia m being very formal in the sense that AAA is a
protocol and not
a server.

And BTW I don't think we need to have an RFC to define a
Key Holder
function in RADIUS servers.
 
> > 
> > > -----Original Message-----
> > > From: Salowey, Joe [mailto:jsaloweycisco.com]
> > > Sent: Thursday, March 09, 2006 11:59 PM
> > > To: Narayanan, Vidya; Avi Lior; Jari Arkko
> > > Cc: eapfrascone.com
> > > Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
> > > 
> > >  
> > > 
> > > > 
> > > > I guess when you say EAP Authentication
Server, it is a 
> bit vague 
> > > > about whether that is the EAP layer or
AAA layer. I'm 
> not sure if 
> > > > there is value in clarifying this or if
it makes more sense
> > > to leave
> > > > it to implementation.
> > > >
> > > [Joe] I'm pretty convinced it is in EAP.  In
the pictures the AAA 
> > > layer appears to carry communication between
AAA client and AAA 
> > > server, I do not think this is where the EMSK
belongs.
> > > 
> > >  
> > > 
> > 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

Avi Lior wrote:

>>[Joe] I think a AAA server is typically composed of
several 
>>components.
>>One of these can be a key holder.  I don't see why
you 
>>couldn't define new functionality in RADIUS to
interact with 
>>the key holder (other than the fact that it seems to
be 
>>difficult to define anything new in RADIUS). 
>>    
>>
>
>[Avi]  Aboslutely correct on all fronts .  A AAA
server can have
>EAP-AS (authetncation server) and a key holder/key
generator.  So I
>guess ia m being very formal in the sense that AAA is a
protocol and not
>a server.
>
>And BTW I don't think we need to have an RFC to define
a Key Holder
>function in RADIUS servers.
>  
>
First of all, I think this part of the discussion is largely
just
a matter of vague definitions making it hard to make exact
statements. E.g. where is the line between AAA as a
"transport" and as an "application"
that has intelligence
to make decisions and grant resources such as keys?

Just to repeat what we have already established, I think
we have consensus that (a) EMSK is generated by EAP
methods and that (b) its not going to be shipped away
to the access devices. In addition, it seems obvious that
the document we are discussing will not define how AMSKs
are used or transported.

So the conclusion is that the EMSK is kept somewhere
between the EAP method and AAA transport layers.
I would note that this means that it is, in an IETF sense,
within a box and not transported via protocols. I don't
think it makes a lot of sense to debate too long about
what the internal structure of the box is. I'd be happy
saying that it resides in the EAP server. I would in
addition only say the following about the internal
module structures: The EMSK is not communicated
either to the lower layer or the AAA transport layer.
But AMSKs derived from it can be,
and that any such derivation would have to be defined
in future documents.

Finally, I dislike the idea that we would be adding
major functionality (such as key server) to IETF
protocols and mechanisms without properly
documenting how they will be used and what the
protocols will exactly carry. The role of the EAP
keying framework is to leave some key material
in the EAP server to enable such functionality,
but if we are going to use it, we will need, among
other things, protocol descriptions on how
RADIUS can retrieve pieces of this key information
and how particular applications employ these
keys.

--Jari

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

Hi Jari

>First of all, I think this part of the discussion is
largely just
>a matter of vague definitions making it hard to make
exact
>statements. E.g. where is the line between AAA as a
>"transport" and as an
"application" that has intelligence
>to make decisions and grant resources such as keys?
>  
>
I agree on you this. In my mind the AAA server (where EAP
server might 
be co-located) is (or should be) intelligent enough to
manage keys from 
users.

>Just to repeat what we have already established, I think
>we have consensus that (a) EMSK is generated by EAP
>methods and that (b) its not going to be shipped away
>to the access devices. In addition, it seems obvious
that
>the document we are discussing will not define how AMSKs
>are used or transported.
>  
>
>So the conclusion is that the EMSK is kept somewhere
>between the EAP method and AAA transport layers.
>  
>
So far, between EAP methods and AAA transpor layers (AAA
server?? ) we 
have EAP authenticator layer and EAP layer. An as specified 
draft-ietf-eap-keying-10.txt both layers cannot cache
anything. I think 
it does not preclude the use of EMSK but it establishes
limits to the 
creation of AMSK. That is, the AMSK should be created just
in the moment 
the EMSK is exported. If EMSK wants to be cached, that part
of text 
should be relaxed, no?

>I would note that this means that it is, in an IETF
sense,
>within a box and not transported via protocols. I don't
>think it makes a lot of sense to debate too long about
>what the internal structure of the box is. I'd be happy
>saying that it resides in the EAP server. I would in
>addition only say the following about the internal
>module structures: The EMSK is not communicated
>either to the lower layer or the AAA transport layer.
>But AMSKs derived from it can be,
>and that any such derivation would have to be defined
>in future documents.
>  
>
I have seen during discussions and also under my
understanding of 
draft-aboba-eap-keying-extns-00.txt that either 1) AMSK
would be 
tranported from AAA server to some entity or 2) AMSK could
be used as a 
root and cached by the AAA server to derive new keys which
would be 
eventually transported to different entities.

will that decision between both cases be specified for
application? or 
would it be better to select one approach (it seems people
like second one)?

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: rafadif.um.es
------------------------------------------------------

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

An additional comment, I have been wondering about EAP peer
side and EAP 
authenticator side.

In the EAP peer side, I have some doubts:

It seems following the same that it has been discussed for
EAP server, 
that EAP peer would create the same set of AMSKs than EAP
server.
And then  AMSKs should be exported to lower layer correct?. 
However I 
do not know if the bunch of AMSKs should be exported to the
EAP lower 
layer or
to another "lower layers". Maybe I am wrong, but
I was assuming each 
"application" could have different lower layers
to interact with 
different "authenticators" . And (possibly) each
AMSK is intended to be 
used with each different authenticator.

Additionally, I was wondering how it affects to "Mode
Independence". EAP 
peer might think that EAP authenticator has MSK and AMSKs
(or keys 
derived from them), is that correct?. Also , would it make
sense to 
create AMSKs in case of standalone EAP authenticator?

Thanks.

>


-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: rafadif.um.es
------------------------------------------------------

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

Rafa Marin Lopez wrote:

>>
>>  
>>
>> So the conclusion is that the EMSK is kept
somewhere
>> between the EAP method and AAA transport layers.
>>  
>>
> So far, between EAP methods and AAA transpor layers
(AAA server?? ) we
> have EAP authenticator layer and EAP layer. An as
specified
> draft-ietf-eap-keying-10.txt both layers cannot cache
anything. I
> think it does not preclude the use of EMSK but it
establishes limits
> to the creation of AMSK. That is, the AMSK should be
created just in
> the moment the EMSK is exported. If EMSK wants to be
cached, that part
> of text should be relaxed, no?

I think so.

>  
> I have seen during discussions and also under my
understanding of
> draft-aboba-eap-keying-extns-00.txt that either 1) AMSK
would be
> tranported from AAA server to some entity or 2) AMSK
could be used as
> a root and cached by the AAA server to derive new keys
which would be
> eventually transported to different entities.
>
> will that decision between both cases be specified for
application? or
> would it be better to select one approach (it seems
people like second
> one)?

I think the practical approach would be to take one
application and
specify how its done
for that. Other applications may later use the same approach
or
something else, if
their requirements differ.

--Jari


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

Hi Jari...

>> 
>>I have seen during discussions and also under my
understanding of
>>draft-aboba-eap-keying-extns-00.txt that either 1)
AMSK would be
>>tranported from AAA server to some entity or 2) AMSK
could be used as
>>a root and cached by the AAA server to derive new
keys which would be
>>eventually transported to different entities.
>>
>>will that decision between both cases be specified
for application? or
>>would it be better to select one approach (it seems
people like second
>>one)?
>>    
>>
>
>I think the practical approach would be to take one
application and
>specify how its done
>for that. Other applications may later use the same
approach or
>something else, if
>their requirements differ.
>  
>
Yes , that's good. As first example of 2), section 2.3 in 
draft-aboba-eap-keying-extns-00.txt. Maybe it would be
interesting to 
start discussing from this application. But in any case, 
did you have 
any other in mind?.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: rafadif.um.es
------------------------------------------------------

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

It seems that we have converged on this issue. Is there
anyone who would like to suggest specific text changes?


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

Jari Arkko wrote:

>It seems that we have converged on this issue. Is there
>anyone who would like to suggest specific text changes?
>  
>
Hi Jari

As I commented in a previous e-mail, I think this paragraph
in section 
2.2 (page 14) should be relaxed if we consider EAP peer /
EAP 
authenticator layer or EAP layer could be in charge of
creating AMSK and 
also if we consider EMSK could be cached in those layers.

"The EAP peer and authenticator layers MUST NOT modify
or cache keying
   material or parameters (including Channel Bindings)
passing in either
   direction between the EAP method layer and the EAP layer.
 The EAP
   layer also MUST NOT cache keying material or parameters
(including
   Channel Bindings) passed to it, whether by the EAP
peer/authenticator
layer, the lower layer or the AAA layer."

Additionally, that paragraph seems a bit contradictory with
this in page 15.

"The EMSK is reserved for future use and MUST remain
on the EAP
      peer and EAP server where it is derived; it MUST NOT
be
      transported to, or shared with, additional parties, or
used to
      derive any other keys.  (This restriction will be
relaxed in a
      future document that specifies how the EMSK can be
used.)"

Could we say ...

"The EMSK is reserved for future use and MUST remain
on the EAP
      peer and EAP server where it is derived; it MUST NOT
be
      transported to, or shared with, additional
parties." ?


>
>________________________________________________________
_________
>To unsubscribe or modify your subscription options,
please visit:
>http:/
/lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.
frascone.com/pipermail/eap
>
>
>  
>


-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: rafadif.um.es
------------------------------------------------------

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap