Subject: Re: [Isms] RADIUS/VACM issue 6

From: "David Harrington" <[email-masked]>
Date: Mon, 1 Mar 2010 11:26:05 -0800

hi,

I am away from this discussion, so I'm dealing with the question out
of context.
what would another reasonable choice?
I believe it was/is important that this is the **transport model**
session ID,
not the **transport** session id.
I think that was the point of the comment.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Randy Presuhn
> Sent: Friday, February 26, 2010 1:13 AM
> To: [email-masked]
> Subject: Re: [Isms] RADIUS/VACM issue 6
> 
> Hi -
> 
> > From: "Juergen Schoenwaelder"
<[email-masked]>
> > To: "Randy Presuhn" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, February 26, 2010 12:52 AM
> > Subject: Re: [Isms] RADIUS/VACM issue 6
> ...
> > Would it make sense to spell out that this could be the 
> tlstmSessionID
> > so that implementors do not have to wonder why 
> tlstmSessionID was not
> > picked in the first place? It might be OK to allow other
identifiers
> > but since the object name carries SessionID in its name, it 
> might even
> > make sense to default this to tlstmSessionID, no?
> 
> How about this?
> 
> extVacmTransportSessionID OBJECT-TYPE
>     SYNTAX       Unsigned32
>     MAX-ACCESS   not-accessible
>     STATUS       current
>     DESCRIPTION "A transport model-specific identifier of the
>                  session.  This value MUST be unique among all
>                  of a given transport model's currently open
sessions.
>    The value has no particular significance other
>    to distinguish sessions.  An example of a suitable
>    value would be tlstmSessionID."
>     ::= { extVacmSecurityToGroupEntry 3 }
> 
> Randy
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 1 Mar 2010 11:40:34 -0800

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Monday, March 01, 2010 11:26 AM
> Subject: RE: [Isms] RADIUS/VACM issue 6
...
> I think that was the point of the comment.

Ok, I'll make the change.

As a matter of "minimum critical specification",
it needs to be unique within the scope of a security model,
which would make a difference if we ever get a security model that
somehow supported multiple transport models.  From an implementor's
point of view, this seems very straightforward, but it's not clear to
me how it fits in with the transport subsystem architecture.  (Though
this document is clearly *not* the place to try to clarify how the transport
subsystem works!)

I'd appreciate guidance on the terminology here - e.g. when to use "secure
transport model", "transport model" and "security model".

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 01 Mar 2010 14:47:07 -0800

>>>>> On Fri, 26 Feb 2010 01:12:48 -0800, "Randy Presuhn" <[email-masked]> said:

RP> How about this?

RP> extVacmTransportSessionID OBJECT-TYPE
RP> SYNTAX       Unsigned32
RP> MAX-ACCESS   not-accessible
RP> STATUS       current
RP> DESCRIPTION "A transport model-specific identifier of the
RP> session.  This value MUST be unique among all
RP> of a given transport model's currently open sessions.
RP> The value has no particular significance other
RP> to distinguish sessions.  An example of a suitable
RP> value would be tlstmSessionID."
RP> ::= { extVacmSecurityToGroupEntry 3 }

Color me confused...  I thought that you'd do something more generic.
tlstmSessionID is specific to the TLS-TM transport.  Wouldn't
tmSessionID be a better choice to reference, which is common to both
TLSTM and SSHTM?  (and tmSessionID == tlstmSessionID in TLSTM)
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 1 Mar 2010 16:39:01 -0800

Hi -

> From: "Wes Hardaker" <[email-masked]>
> Sent: Monday, March 01, 2010 2:47 PM
> Subject: Re: RADIUS/VACM issue 6
...
...

Ok, I'll use that.

(I don't have strong feelings about this.  It's only an example, and the
only real requirement is that it be unique in the scope of the security
model with which it is associated)

Randy