Subject: [Isms] Tmsm#6: double-authentication

From: "David Harrington" <[email-masked]>
Date: Fri, 16 Feb 2007 11:01:48 -0500

Hi,

I did not originally consider this an open issue, but I suppose I
should.

- last para of sect 3.2.2.1

    If the type of authentication provided by the transport layer
(e.g.
    TLS) is considered adequate to secure and/or encrypt the message,
but
    inadequate to provide the desired granularity of access control
(e.g.
    user-based), then a second authentication (e.g., one provided via
a
    RADIUS server) MAY be used to provide the authentication identity
    which is bound to the securityName.  This approach would require a
    good analysis of the potential for man-in-the-middle attacks or
    masquerade possibilities.

Bert (1/9):
  It does not say anything about at what point in the process steps
this
  mapping from RADIUS authenticated identity to a securityName needs
  to take place. Maybe we want to leave that open. But it seems to me
  that the least we can say is that: it MUST bde done for incoming
  messages before the security model passes securityName to the
message
  processing model via the processIncoming() ASI. 

DBH: I'm not sure that's true. If the goal is to get the identity for
access control, it really only needs to get the securityname before it
provides access control. If, for example, it uses RADIUS and does an
authentication of the user and gets the authorization data, it could
do this as part of the access control model. it doesn't need to be
bound to the securityModel of the message, does it? I haven't spent
time to consider the security implications of this, but I don't think
we need to force this to be done a particular way. Of course, we do
want to make sure the sender of the message is authorized to use the
credentials that will authenticate the RADIUS request.

Bert:
First, none of the ASIs doe prescribe a particular way of 
implementation. The ASIs are to pass stuff between 
modularized documents.

Second, although in theory it maybe OK to do it rigth before
access control, I personally think it is cleaner (from a
documentation modularity point of view) that it is done
as I suggested. All the other ASIs have the securityName as a 
paramter, and so I think it is more consistent if that paramter
is filled out before such a field is being passed around.

DBH (new):
I agree that the security model has the responsibility for determining
for incoming messages which securityname/level parameters will passed
to MPM, to be passed deeper into the system. 

[Just to be clear on this somewhat related point, the security model
might determine securityname/level from the message itself (e.g. USM),
or from a cache (e.g. TSM), or from a MIB (e.g. RFC3584 Community-SM);
it is security-model-dependent how these are determined. They are
passed to the MPM and then to the rest of the system.]

The securityname/level/model parameters provided by MPM COULD be used
by an access control model, but there is nothing that says the access
control model MUST use them.

Applications are the typical clients of the service(s) of the Access
Control Subsystem. The MPM passes securityname/level/model to the
disptacher, which passes them to the application. Assuming an
application wanted to do so, the application could take the
MPM-provided securityname/level/model (e.g. dbh/authpriv/tsm) and look
up some RADIUS credentials (e.g. dharrington and some keys), talk to a
RADIUS server to authenticate the principal (e.g. dharrington), and
then use the RADIUS-supplied principal in the securityname/level/model
parameters for the call to isAccessAllowed. 

An alternative (that is more consistent with RFC4311 modularity):
An access control model could accept the securityName (e.g. dbh)
provided by the securityModel-MPM-application in the isAccessAllowed
ASI, and THEN could translate that into RADIUS parameters
(dharrington), talk to RADIUS, and then use the RADIUS-principal
(dharrington) as the mapping to securityName used in the VACM MIB.

Again, I agree that the security model has the responsibility for
determining for incoming messages which securityname/level parameters
will passed to MPM, to be passed deeper into the system. 

But I think we want to be careful mandating that any "mapping from
RADIUS authenticated identity to a securityName MUST be done for
incoming messages before the security model passes securityName to the
message processing model".

David Harrington
[email-masked] 
[email-masked]
[email-masked]

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Mon, 19 Feb 2007 15:40:42 +0100

Inline at the bottom (so people can follow the discussion
by just reading this email): 

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: vrijdag 16 februari 2007 17:02
> To: [email-masked]
> Subject: [Isms] Tmsm#6: double-authentication
> 
> Hi,
> 
> I did not originally consider this an open issue, but I 
> suppose I should.
> 
(e.g.
but
(e.g.
a
this
message
> DBH: I'm not sure that's true. If the goal is to get the 
> identity for access control, it really only needs to get the 
> securityname before it provides access control. If, for 
> example, it uses RADIUS and does an authentication of the 
> user and gets the authorization data, it could do this as 
> part of the access control model. it doesn't need to be bound 
> to the securityModel of the message, does it? I haven't spent 
> time to consider the security implications of this, but I 
> don't think we need to force this to be done a particular 
> way. Of course, we do want to make sure the sender of the 
> message is authorized to use the credentials that will 
> authenticate the RADIUS request.
> 
> Bert:
> documentation modularity point of view) that it is done as I 
> suggested. All the other ASIs have the securityName as a 
> paramter, and so I think it is more consistent if that 
> paramter is filled out before such a field is being passed around.
> 
> DBH (new):
> I agree that the security model has the responsibility for 
> determining for incoming messages which securityname/level 
> parameters will passed to MPM, to be passed deeper into the system. 
> 
> [Just to be clear on this somewhat related point, the 
> security model might determine securityname/level from the 
> message itself (e.g. USM), or from a cache (e.g. TSM), or 
> from a MIB (e.g. RFC3584 Community-SM); it is 
> security-model-dependent how these are determined. They are 
> The securityname/level/model parameters provided by MPM COULD 
> be used by an access control model, but there is nothing that 
> says the access control model MUST use them.
> 
> Applications are the typical clients of the service(s) of the 
> Access Control Subsystem. The MPM passes 
> securityname/level/model to the disptacher, which passes them 
> to the application. Assuming an application wanted to do so, 
> the application could take the MPM-provided 
> securityname/level/model (e.g. dbh/authpriv/tsm) and look up 
> some RADIUS credentials (e.g. dharrington and some keys), 
> talk to a RADIUS server to authenticate the principal (e.g. 
> dharrington), and then use the RADIUS-supplied principal in 
> the securityname/level/model parameters for the call to 
> isAccessAllowed. 
> 
> An access control model could accept the securityName (e.g. 
> dbh) provided by the securityModel-MPM-application in the 
> isAccessAllowed ASI, and THEN could translate that into 
> RADIUS parameters (dharrington), talk to RADIUS, and then use 
> the RADIUS-principal
> Again, I agree that the security model has the responsibility 
> for determining for incoming messages which 
> securityname/level parameters will passed to MPM, to be 
> passed deeper into the system. 
> 
> But I think we want to be careful mandating that any "mapping 
> from RADIUS authenticated identity to a securityName MUST be 
> done for incoming messages before the security model passes 
> securityName to the message processing model".
> 

I agree we need to be carefull.
But all the ways you describe above in how things COULD be done
is exactly the reason why I prefer we describe how we EXPECT it
to be done, so that we easily get compliant and interoperable
implementations (I agree that this is not on-the-wire-interoperability,
but I think it is also important to ensure that if you have agents 
from 3 different vendors, that they more or less apply access control
consistently.

In RFC3411, we have described in Sect 4.3 the ASI for the
Access Control Subsystem. Not for VACM, but for the Subsystem. SO
to me that means that we intended that all Access Control Models 
would (preferably) use that ASI and the paramters that come with
it.

Further, I would hope that the ISMS implementation will be able to
use VACM as an Access Control Model, and so it would be BEST (in my
view) if the parameters are properly populated at one place
so that they get passed as specified in the ASI.

Further, I am not sure that it is wise (I understand it is possible)
to have a dbh securityName from some transport model, and then later
get a dharrington as the identity for access control. I would MUCH MUCH 
more prefer that this also is the securityName.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Feb 2007 15:41:08 +0100

On Mon, Feb 19, 2007 at 03:40:42PM +0100, Wijnen, Bert (Bert) wrote:

> >     If the type of authentication provided by the transport layer (e.g.
> >     TLS) is considered adequate to secure and/or encrypt the message, but
> >     inadequate to provide the desired granularity of access control (e.g.
> >     user-based), then a second authentication (e.g., one provided via a
> >   It does not say anything about at what point in the process steps this
> >   messages before the security model passes securityName to the message

Why do we have to talk about this in this document at all? Is it not
the job of the RADIUS integration document to spell out when and where
in the processing RADIUS can be called, which attributes are relevant
and how the RADIUS interaction may change values of things such as the
securityName? Such a document should then be precise where things
happen.

I would like to treat a secure transport model as a block box which
provides me with an authenticated securityName etc. and I would leave
it to the specifications of such a secure transport model to tell me
how things work (and this includes AAA services such as RADIUS).

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 27 Feb 2007 22:20:52 +0100

Inline 

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: dinsdag 27 februari 2007 15:41
> To: Wijnen, Bert (Bert)
> Cc: David Harrington; [email-masked]
> Subject: Re: [Isms] Tmsm#6: double-authentication
> 
> Why do we have to talk about this in this document at all? Is 
> it not the job of the RADIUS integration document to spell 
> out when and where in the processing RADIUS can be called, 
> which attributes are relevant and how the RADIUS interaction 
> may change values of things such as the securityName? Such a 
> document should then be precise where things happen.
> 

CHANGING the securityName at some point during the process?????
I am not so sure this is wise. This is in fact exactly why I
wanted to make sure that we prescribe where the securityName
is determined.

> I would like to treat a secure transport model as a block box 
> which provides me with an authenticated securityName etc. and 
> I would leave it to the specifications of such a secure 
> transport model to tell me how things work (and this includes 
> AAA services such as RADIUS).
> 

Yep.... but once we start processing the message, I think that is where
we want to be sure we have securtyName, securityLevel and that such do
not change anymore.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Feb 2007 09:49:39 +0100

> wanted to make sure that we prescribe where the securityName

My understanding of RFC 3411 is that the security model determines
the securityName. We do not change that by introducing a transport
subsystem. The transport security model says that the securityName
is provided by the secure transport and accessed via the 
tmStateReference. I believe this is what the documents should say.
We should refrain from discussing RADIUS or any other fancy AAA
service that can/might/... be called in the transport subsystem
and the transport security model documents.

[Note that I did not suggest to change securityName - but I do
 believe that RADIUS might be called during the processing, e.g.
 to obtain a securityName to groupName mapping. So I believe my
 quoted comment above stands.]
 
> we want to be sure we have securtyName, securityLevel and that such do

I agree. I would expect that a document which proposed to call RADIUS
in the middle of the processing to change parameters will have to come
up with a very convincing story. My point at this time is to get the
open issues on the transport subsystem document closed and I believe
we do not need to discuss RADIUS aspects in the transport subsystem
document.

/js

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Wed, 28 Feb 2007 17:54:52 +0100

Inline 

> Sent: woensdag 28 februari 2007 9:50
> To: Wijnen, Bert (Bert)
> > > the job of the RADIUS integration document to spell out when and 
> > > where in the processing RADIUS can be called, which 
> attributes are 
> > > relevant and how the RADIUS interaction may change values 
> of things 
> > > such as the securityName? Such a document should then be precise 
> > > where things happen.
> > > 
> > 
> > I am not so sure this is wise. This is in fact exactly why I wanted
to 
> > make sure that we prescribe where the securityName is determined.
> 
> My understanding of RFC 3411 is that the security model 
> determines the securityName. We do not change that by 
> introducing a transport subsystem. The transport security 
> model says that the securityName is provided by the secure 
> transport and accessed via the tmStateReference. I believe 
> this is what the documents should say.

Rigght, and when we come back from the security-model, then we DO have
the
securityName as a paramter that passes along the subsequent ASIs.
And so, I would get worried if some access model (or whatever) can later
call RADIUS and change the securityName. And so that is what I
thought we ought to specify.

Bert
> We should refrain from discussing RADIUS or any other fancy 
> AAA service that can/might/... be called in the transport 
> subsystem and the transport security model documents.
> 
If it gets called at those places, I am fine.
I believe DBH suggested it could be called later in the process,
and that would make me worried.

> [Note that I did not suggest to change securityName - but I 
> do  believe that RADIUS might be called during the processing, e.g.
>  to obtain a securityName to groupName mapping. So I believe 
> my  quoted comment above stands.]
>  
> > > provides me with an authenticated securityName etc. and I would 
> > > leave it to the specifications of such a secure transport 
> model to 
> > > tell me how things work (and this includes AAA services such as 
> > > RADIUS).
> > > 
> > 
> > Yep.... but once we start processing the message, I think that is 
> > where we want to be sure we have securtyName, securityLevel 
> and that 
> > such do not change anymore.
> 
> I agree. I would expect that a document which proposed to 
> call RADIUS in the middle of the processing to change 
> parameters will have to come up with a very convincing story. 
> My point at this time is to get the open issues on the 
> transport subsystem document closed and I believe we do not 
> need to discuss RADIUS aspects in the transport subsystem document.
> 
> /js
> 
> --