Subject: [IPTEL] A plea for help from the iptel working group

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Nov 2000 20:39:59 -0500

Folks,

There is only one remaining open issue with TRIP
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt

and it is one that the authors cannot resolve without assistance.

THe issue is authentication for attributes. The authors think that this
feature is still useful. However, we need to have a set of algorithms, and a
specific encoding format for those algorithms, to be included in the spec. I
believe that this authentication encoding will need to include the
certificate for the signer, since an LS may not have a pre-arranged
relationship with the originator of a route.

We need help in coming up with a set of algorithms (we suspect DSA and RSA,
but need additional guidance on what more, if anything, needs to be said)
and their encoding, including the certs, within TRIP. Actual text for
inclusion in the draft is specifically what we want, not suggestions like
"check out protocol foo", since invariably, what protocol foo has isn't
quite right (i.e., uses ASN.1 or XML or something we don't have). 

So, this is a PLEA for assistance. 

If someone cannot contribute some text here, we may be forced to remove this
feature all together in the baseline draft, and relegate it to a separate
I-D. That may or may not go over well with the A-Ds either.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Paul Krumviede <[email-masked]>
Date: Thu, 16 Nov 2000 19:37:02 -0800

one preliminary note: i'm not on the iptel mailing list, so i won't see
responses, comments, what have you, sent only there...

> relationship with the originator of a route.

some of the smime work, particularly that on CMS (RFC 2630) would,
in some ways fit the need well (among other things one gets encoding
of the result and some algorithms), but the syntax for using that directly
might be a problem given that a syntax for an authentication attribute
already exists in TRIP.

CMS "describes an encapsulation syntax for data protection." one
nest encapsulations, which in some scenarios can come in handy.

if using the signed-data content type, signer-specific information
is collected into a particular structure, including certificates.
it isn't clear to me if the CMS authenticated-data content type
can be used in this scenario, as it requires encrypting some
keying material (for use with a MAC algorithm) for each recipient,
with the details of the encryption depending on what key management
is being used.

by "encoding format for those algorithms" i'm assuming that
one needs to be able to specify the algorithm(s) as well as
the syntax of the signature and related information (such as
certificates), not just a way to encode which algorithm(s)
were used.

> and their encoding, including the certs, within TRIP.

as to algorithms, one issue might be how one wishes to authenticate
an attribute. in particular, should one compute some form of digest,
using something like MD5 or SHA-1, and then sign the digest? RSA
and DSA seem reasonable choices for signature algorithms.

> Actual text for

CMS uses ASN.1. To the extent that an implementation may have
to handle certificates, an implementation would need to support
ASN.1 (unless one wants to consider different approaches, such as the
SPKI/SDSI stuff, but that is likely to have problems). how much of a
problem would ASN.1 be?

> I-D. That may or may not go over well with the A-Ds either.

without some better understanding of the constraints, supplying text will
be hard.

-paul

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2000 11:20:38 -0800 (PST)

Jonathan,

Maybe this is irrelevant since the draft deadline
passed, but I predictably am in favor of avoidance
of problems that cry out for public key solutions
unless there is some absolute and unavoidable
reason why they are necessary. If this were BGP,
I would be *very* concerned about the implications
of the number of public key signatures and
verifies. However, TRIP is not BGP, so it's hard
for me to guage whether it's unavoidable or not.

Maybe it really would be the better part of valor
to leave it out until we have some operational
experience?

			Mike