text:
A Big Opportunity – For Everyone
Spinal Cord Injury (SCI) refers to an injury to the spinal cord that is caused by direct trauma or secondary damage to the surrounding bone, tissue, or blood vessels. Classification of the extent of the injury is based on neurological responses, touch and pinprick sensations tested in each dermatome (an area of the skin supplied by a single spinal nerve), and strength of ten key muscles on each side of the body, including the hip flexion (L2), shoulder shrug (C4), elbow flexion (C5), wrist extension (C6), and elbow extension (C7). The four categories of SCI classification and their respective percent of the market are: Complete Tetraplegia (16%), Incomplete Tetraplegia (41%), Complete Paraplegia (22%), and Incomplete Paraplegia (21%) (source).
Incidence of spinal cord injury occurs at about 40 cases per 1 million persons. In the U.S., we estimate there are approximately 12,000 new cases per year. Include Canada and Western Europe and the total number of new cases per year is around 20,000. Adding in India, China, Australia, Latin America and Japan and the total grows to over 100,000 new (acute) cases of SCI worldwide per year. Prevalence of SCI in the U.S. is around 300,000 individuals between the U.S. and Canada. We estimate that 75% of these patients would benefit from a new treatment paradigm.
According to the National Spinal Cord Injury Center, the mean age of an SCI patient is 41 (median 38), although a large number of injuries occur from motor vehicle crashes in persons between the ages of 16 and 30. Life expectancy (for persons that survive the first 24 hours) decreases with the severity of the injury. Below are statistics from the National Spinal Cord Injury Statistic Center on life expectancy vs. SCI severity:
SCI can be caused by any number of injuries to the spine. The most common is vehicular crashes, at roughly 40% of all SCI cases. Accidental falls account for another 28% of SCI cases. Violent crimes, with or without a firearm, account for another 15%. Sports related injuries account for 8% as well, with diving making up 75% of all sports-related SCI injuries, followed by snow skiing, football and surfing.
Injuries from vehicle accidents usually occur through direct trauma, or through cuts or protruding fragments of metal. Direct damage can also occur if the spinal cord is pulled, pressed sideways, or compressed. This may occur if the head, neck, or back are twisted abnormally; this is typical in sports-related injuries. Individuals prone to falls, such as patients with multiple sclerosis, epilepsy, stroke, or osteoporosis, are at high risk for SCI. Although, most spinal cord injuries occur in young, healthy men, typically through vehicle accidents or sports-related injuries.
Symptoms of SCI vary greatly with the severity and location of the injury. SCI causes weakness, loss of motor function, and sensory loss at and below the point of injury. The severity of the symptoms depends on whether the entire cord is severely injured (complete) or only partially injured (incomplete).
A complete injury frequently means that the patient has little hope of functional recovery. The relative incidence of incomplete injuries compared to complete spinal cord injury has improved over the past half century, due mainly to the emphasis on better initial care and stabilization of spinal cord injury patients. Incomplete SCI accounts for approximately 62% of all SCI cases, up from below 45% in 1970. Most patients with incomplete injuries recover at least some function.
In addition to sensation and muscle control, the loss of connection between the brain and the rest of the body can have specific effects depending on the location of the injury. Patients with SCI can experience pain, weakness, spasticity, loss of bowel and bladder control, sensory changes, numbness, loss of sexual function, and difficulty breathing. Other complications include blood pressure changes, chronic kidney disease, deep vein thrombosis, contractures, pulmonary infections, skin infections, urinary tract infections, and pressure ulcers.
The time between the injury and treatment is a critical factor affecting prognosis. Spinal cord trauma is a medical emergency and requires immediate surgical attention. The primary objective is to remove fluid or tissue pressing on the spinal cord (decompression laminectomy), remove bone fragments, disk fragments, or other foreign objects that could do further damage, and then stabilize the cord by fusing bone or implanting spinal braces. In some cases, if spinal cord compression is caused by a mass, such as a hematoma or bone fragment, removal may improve the paralysis. Surgery is often followed by use of corticosteroids, such as dexamethasone or methylprednisolone, to reduce secondary swelling that may damage the spinal cord. Corticosteroids should begin as soon as possible after the injury because it is often this secondary inflammation and immune response that does the long-term damage to the spinal cord. Ideally, patients with SCI should be on bedrest to allow the bones in the spine to heal. Spinal traction or a neck brace may be useful in aiding in reducing secondary damage to the weakened bone.
Following a SCI, the nerve cells below the level of injury become disconnected from the brain. This is due to scar tissue which forms in the structure of the damaged area of the spinal cord, blocking messages from the brain to below the level of injury. This can cause muscle spasticity. However, spasticity may not occur immediately following an injury. Often the body is in shock following SCI; this may last several weeks. During this time, changes occur to the nerve cells which control muscle activity. Once spinal shock wears off, the natural reflex reappears, which may be followed by spasticity if there is structural damage in the cord. Spasticity may also cause pain, loss of range of motion, contractures, sleep disorders and impair ambulation in patients with an incomplete lesion. Medications like Botox, baclofen, dantrolene, and tizanidine may be used to control spasticity. We note that none of these above pharmaceutical options, either corticosteroids, anti-inflammatory drugs, or anti-spasticity drugs, are designed to treat paralysis.
Extensive physical therapy, occupational therapy, and other intense rehabilitation therapies are often required after the acute injury has healed. Much of the rehabilitation takes place in a hospital or acute care setting. The average hospital stay for someone with SCI is two weeks. However, the average stay in the rehabilitation unit is five weeks. We note the trend over the past decade has been towards shorter inpatient rehabilitation and longer post discharge therapy.
Historically, the leading cause of death among persons with SCI has been renal failure. However, today, the leading causes of death are pneumonia, pulmonary emboli, and septicemia. In addition, pain resulting from SCI can be debilitating. Immobility can lead to muscle atrophy and pressure ulcers. Infections are a major life-threatening side-effect of paralysis. Besides corticosteroids, spasticity medications, and pain medications, SCI patients may find themselves on and off antibiotics and antifungal agents to combat infections.
The acute care market for SCI is significant. Below are estimates of what it costs, per year, to treat and care for an SCI patient by severity, and what lifetime costs are for SCI patients ages 25 and 50.
Combining our stats from above, we calculate that each year, in the U.S., nearly $18 billion is spent for the care of patients with SCI. It's an enormous market opportunity and one where significant new medical breakthroughs are necessary. Besides the estimated $18 billion being spent for acute SCI patients each year. We estimate another $20 billion is being spent each year on chronic care for patients. These costs include hospitalizations, nursing homes, new catheters, rehabilitation, wheel chairs, etc. Yet, even with this significant amount of money being spent, there are no approved pharmaceutical or medical device treatments to cure paralysis.
Three Names To Watch
On January 14, 2013, Neuralstem, Inc. (CUR) announced the U.S. FDA had granted approval to start a phase 1 safety trial testing NSI-566, the company's human spinal cord stem cells, in patients with chronic spinal cord injury. The trial is designed to be an open-label assessment of NSI-566 at multiple sites around the U.S. Neuralstem will seek to enroll eight patients with thoracic spinal cord injuries (T2-T12), who have an American Spinal Injury Association (ASIA) A level of impairment, between one and two years after injury. ASIA-A impairment refers to a patient with no motor or sensory function in the relevant segments at and below the injury (complete paralysis).
All patients in the study will receive six injections in or around the injury site. The first four patients will receive 100,000 cells per injection, the second four patients will receive 200,000 cells per injection. All patients will also receive physical therapy post surgery, as well as immunosuppressive therapy, which will be for three months, as tolerated. The trial study period will end six months post-surgery for each patient.
The primary objective of the study is to determine the safety and toxicity of NSI-566 transplantation for the treatment of paralysis and related symptoms due to chronic spinal cord injury. We remind investors that the investigational new drug (IND) for this application was originally filed in August 2010. The FDA put a hold on Neuralstem initiating the study while the company collected additional safety data from the ongoing phase 1 study in patients with amyotrophic lateral sclerosis (ALS).
The secondary objectives of the study are to evaluate graft survival in the transplant site by MRI, as well as the effectiveness of transient immunosuppression. DNA fingerprinting analysis from the phase 1 ALS trial shows the company was able to establish long-term survival of NSI-566 post transplant independent of immune suppression medication that can cause tolerability and side-effect issues.
This is big news because it means that Neuralstem's spinal cord stem cells not only survived the procedure, but also grafted as designed to potentially rebuild circuitry and protect existing neurons from further degradation from the disease. We've written previously about our belief that NSI-566 has demonstrated some benefit to select patients with ALS.
Neuralstem will also seek to collect efficacy data from the phase 1 study, looking at potential changes in ASIA level, ISNC SCI motor and sensory index scores, bowel and bladder function, pain, UAB IMR scores, SCIM scores, evoked sensory and motor potentials, and electromyogram (EMG). The open-label design of the planned phase 1 study will allow for a rolling assessment of these outcomes. We would expect data roughly twelve months after the first patient is treated. Neuralstem has published preclinical data demonstrating growth and connectivity of neural stem cells after severe spinal cord injury in rats. Additional work shows functional recovery of rats with ischemic paraplegia after receiving Neuralstem's spinal stem cells.
Besides Neuralstem, perhaps no company has generated more enthusiasm in spinal cord injury than InVivo Therapeutics (NVIV.OB). InVivo's biodegradable polymer scaffolding device was designed to promote long-term functional recovery following an acute spinal cord injury. InVivo takes a completely different approach from Neuralstem. The device provides protection to the spinal cord and prevention from secondary injury rather than regeneration from spinal stem cells. InVivo scientists believe it is the secondary immune response and inflammation that does the majority of the tissue damage sustained following an acute injury.
The company's technology (view animation) focuses on minimizing this tissue damage sustained following acute injury and promoting neural plasticity of the spared healthy tissue, which may result in full or partial functional recovery. Rarely does preclinical data create so much excitement in the investment community, but InVivo's preclinical data turned heads in 2011. The company has published data showing that its biodegradable polymer scaffolding device, both in combination with drug and seeded with human neural stem cells, yielded some impressive results.
InVivo plans to publish its full primate data in Nature in the next few months. The company has made available some incredible videos showing the dramatic recovery of previously paralyzed African green monkeys up and running weeks after surgery.
The key question for InVivo is – When do human trials begin? We heard rumblings throughout 2012 that the FDA was pulling back on its previous guidance that the product would be regulated as a device, seeking to regulate the scaffolding as a drug. This pushed the stock down to $1.30 in October 2012. However, on October 12, 2012 the company issued a letter to shareholders noting that the FDA has confirmed the regulation of the scaffold product as a device. This is good news, because it saves the company significant time and money.
In December 2012, InVivo filed a request with the U.S. FDA for a Humanitarian Use Device (HUD) designation. The request came after an April 2012 meeting in which InVivo and the FDA discussed the requirements for the HUD designation and the potential for the device to be regulated and distributed under a Humanitarian Device Exemption (HDE). An HUD designation and a subsequent approved HDE would enable InVivo to commercialize the device in the U.S. faster than the Pre-Market Approval (PMA) process.
InVivo is guiding to start an open-label study in patients with ASIA-A acute thoracic spinal cord injury in the next few weeks. InVivo will seek to enroll five patients at two Level-1 trauma centers in the U.S., Harvard Brigham & Women's in Boston and Geisinger Health System in Philadelphia. We expect enrollment of the first two patients with subsequent follow-up analysis before the next three are enrolled. We expect similar endpoints to the Neuralstem study, with the primary endpoint in safety and secondary endpoints in ASIA score, motor and sensory index scores, bowel and bladder function, etc.
We've received a number of questions from investors on how a five-patient trial can qualify for HDE approval. The number of patients and design of the trial certainly raises questions in our mind. We've seen a number of papers noting that patient selection and protocol design are important when looking at outcomes in patients with spinal cord injury. However, if the trial begins, investment in InVivo at this level is a "no-brainer," specifically because of the potential for spontaneous recovery.
We think InVivo's device works – the primate data and videos are proof. Primate models of spinal cord injury have been validated and peer-reviewed by many respected organizations. Given the complete lack of effective treatment options for ASIA-A acute spinal cord injury patients, if InVivo can demonstrate recovery in just one or two of the five patients, we expect the market to react favorably. However, the U.S. FDA will probably require a more throughout analysis of the device for chronic use.
One final name worth mentioning in this area is StemCells, Inc. (STEM). In December 2010, the company received approval from Swissmedic, the Swiss regulatory agency, to initiate a phase 1/2 clinical trial in Switzerland with its proprietary HuCNS-SC (purified human neural stem cells) product candidate. StemCells, Inc. designed the trial to assess both safety and preliminary efficacy in patients with varying degrees of paralysis who are 3-12 months post-injury.
The trial initiated at the University of Zurich in March 2011. The trial will enroll 12 patients with thoracic (T2-T11) spinal cord injury who have both complete and incomplete injuries as classified by the ASIA Impairment Scale. Management is enrolling patients in three cohorts: Cohort 1 has enrolled patients classified as ASIA-A (complete injury with no movement or feeling below the level of the injury). Data from these three patients was presented in September 2012 at the 51st Annual Scientific Meeting of the International Spinal Cord Society in London, England. Data showed good safety and tolerability, with (what management referred to as) considerable improvement in sensory function. The gains in sensation have evolved in a progressive pattern below the level of injury and are unanticipated in spinal cord injury patients with this severity of injury, suggesting that the neural stem cells are having a beneficial clinical effect. Unlike the acute patients that InVivo plans to enroll, sensory function in all three patients was stable (baselined) before transplantation.
StemCells, Inc. is now progressing with the second cohort, seeking to enroll patients classified as ASIA-B (some degree of feeling below the injury). A third cohort will consist of patients classified as ASIA-C (some degree of movement below the injury). All patients are evaluated regularly for twelve months post treatment, and will be enrolled in a separate four-year observational study at the conclusion of the trial to assess long-term safety and efficacy.
StemCells, Inc. has not received the investor attention that perhaps Neuralstem or InVivo Therapeutics has received over the past few months, perhaps because the trial is being conducted in Switzerland and not the U.S. Conducting trials outside the U.S. can be a cheaper way to generate proof of safety and concept prior to a larger U.S. study. We note Neuralstem plans to conduct a spinal cord injury trial in South Asia with South Korean partner, CJ CheilJedang, in 2013. We remind investors that StemCells, Inc. was awarded a $20 million grant from the California Institute for Regenerative Medicine in July 2012. The goal is to file a U.S. IND in the next four years.
We would be buyers of Neuralstem, not only based on the announcement that the company will start a phase 1 trial in spinal cord injury, but also based on the previous data in ALS and the company's opportunity to partner NSI-189, a phase 1 small molecule asset for depression and anxiety (see related article).
We would be buyers of InVivo Therapeutics on final confirmation that the IDE/HDE trial has initiated. We like the InVivo story, but the delays that hurt the stock throughout 2012 could easily begin to weigh on the shares again in 2013 unless management can push forward very soon.
We are neutral on StemCells, Inc. Spinal cord injury is just a small part of the company's story, and we admittedly have not delved deep enough into the company's programs for Pelizaeus-Merzbacher Disease (PMD) and Dry Age-Related Macular Degeneration (AMD).
Additional disclosure: PropThink is a team of editors, analysts, and writers. This article was written by Jason Napodano, CFA. We did not receive compensation for this article, and we have no business relationship with any company whose stock is mentioned in this article. Use of PropThink's research is at your own risk. You should do your own research and due diligence before making any investment decision with respect to securities covered herein. You should assume that as of the publication date of any report or letter, PropThink, LLC and persons or entities with whom it has relationships (collectively referred to as "PropThink") has a position in all stocks (and/or options of the stock) covered herein that is consistent with the position set forth in our research report. Following publication of any report or letter, PropThink intends to continue transacting in the securities covered herein, and we may be long, short, or neutral at any time hereafter regardless of our initial recommendation. To the best of our knowledge and belief, all information contained herein is accurate and reliable, and has been obtained from public sources we believe to be accurate and reliable, and not from company insiders or persons who have a relationship with company insiders. PropThink was not compensated to publish this article. Our full disclaimer is available at www.propthink.com/disclaimer.
Disclosure: I have no positions in any stocks mentioned, and no plans to initiate any positions within the next 72 hours. I wrote this article myself, and it expresses my own opinions. I am not receiving compensation for it. I have no business relationship with any company whose stock is mentioned in this article.
By Jason Napodano, CFA
Seeking Alpha


text:
Monetize your website traffic by placing adcodes from Adstork publisher account. Adstork gives you money for every valid click from your websites. Our system ensures that ads from highest bidders are rendered on your websites, thereby assuring the maximum revenue possible at any given time.
Adcodes are available as simple one line html code for displaying text or banner ads. Our system supports all industry standard banner dimensions. Adstork adcodes are capable of identifying the most relevant keywords in your websites and generating best matching ads for the same.
You may customize adcodes from Adstork by modifying various style attributes so as to match with your website design. You can also configure filters in your adcodes for restricting your competitor ads from being displayed on your websites.
Track your adcode performance and earnings using the advanced reports provided by our system for different time periods. These reports provide statistics of impressions, clicks, earnings and CTR of your adcodes. The reports help you to identify your top performing adcodes by providing detailed statistics of individual adcodes.
Adstork provides multiple payout options for withdrawing money from your publisher account. You can request payouts using fast and secure Paypal gateway as well as bank or check payments when your balance reaches minimum payout level. You can also transfer funds from your Adstork publisher account to your Adstork advertiser account. History of your payouts can be tracked easily from your account.

subset: commoncrawl


text:
Internet Engineering Task Force (IETF) A. DeKok Request for Comments: 7360 FreeRADIUS Category: Experimental September 2014 ISSN: 2070-1721 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUSAbstract
The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7360.
Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4 1.1. Terminology ................................................5 1.2. Requirements Language ......................................5 1.3. Document Status ............................................5 2. Building on Existing Foundations ................................6 2.1. Changes to RADIUS ..........................................7 2.2. Similarities with RADIUS/TLS ...............................8 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ..............8 3. Interaction with RADIUS/UDP .....................................9 3.1. DTLS Port and Packet Types ................................10 3.2. Server Behavior ...........................................10 4. Client Behavior ................................................11 5. Session Management .............................................12 5.1. Server Session Management .................................12 5.1.1. Session Opening and Closing ........................13 5.2. Client Session Management .................................15 6. Implementation Guidelines ......................................16 6.1. Client Implementations ....................................17 6.2. Server Implementations ....................................18 7. Diameter Considerations ........................................18 8. IANA Considerations ............................................18 9. Implementation Status ..........................................18 9.1. Radsecproxy ...............................................19 9.2. jradius ...................................................19 10. Security Considerations .......................................19 10.1. Crypto-Agility ...........................................20 10.2. Legacy RADIUS Security ...................................21 10.3. Resource Exhaustion ......................................22 10.4. Client-Server Authentication with DTLS ...................22 10.5. Network Address Translation ..............................24 10.6. Wildcard Clients .........................................24 10.7. Session Closing ..........................................25 10.8. Client Subsystems ........................................25 11. References ....................................................26 11.1. Normative References .....................................26 11.2. Informative References ...................................27 Acknowledgments ...................................................27
1. Introduction
The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], and others has traditionally used methods based on MD5 [RFC1321] for per-packet authentication and integrity checks. However, the MD5 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. As a result, some specifications, such as [RFC5176], have recommended using IPsec to secure RADIUS traffic. While RADIUS over IPsec has been widely deployed, there are difficulties with this approach. The simplest point against IPsec is that there is no straightforward way for an application to control or monitor the network security policies. That is, the requirement that the RADIUS traffic be encrypted and/or authenticated is implicit in the network configuration, and it cannot be enforced by the RADIUS application. This specification takes a different approach. We define a method for using DTLS [RFC6347] as a RADIUS transport protocol. This approach has the benefit that the RADIUS application can directly monitor and control the security policies associated with the traffic that it processes. Another benefit is that RADIUS over DTLS continues to be a UDP-based protocol. The change from RADIUS/UDP is largely to add DTLS support, and make any necessary related changes to RADIUS. This allows implementations to remain UDP based, without changing to a TCP architecture. This specification does not, however, solve all of the problems associated with RADIUS/UDP. The DTLS protocol does not add reliable or in-order transport to RADIUS. DTLS also does not support fragmentation of application-layer messages, or of the DTLS messages themselves. This specification therefore shares with traditional RADIUS the issues of order, reliability, and fragmentation. These issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS [RFC6614].
1.1. Terminology
This document uses the following terms: RADIUS/DTLS This term is a shorthand for "RADIUS over DTLS". RADIUS/DTLS client This term refers both to RADIUS clients as defined in [RFC2865] and to Dynamic Authorization clients as defined in [RFC5176] that implement RADIUS/DTLS. RADIUS/DTLS server This term refers both to RADIUS servers as defined in [RFC2865] and to Dynamic Authorization servers as defined in [RFC5176] that implement RADIUS/DTLS. RADIUS/UDP RADIUS over UDP, as defined in [RFC2865]. RADIUS/TLS RADIUS over TLS, as defined in [RFC6614]. silently discard This means that the implementation discards the packet without further processing.1.2. Requirements Language
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].1.3. Document Status
This document is an Experimental RFC. It contains one of several approaches to address known cryptographic weaknesses of the RADIUS protocol, such as described in [RFC6614]. This specification does not fulfill all recommendations for an Authentication, Authorization, and Accounting (AAA) transport profile as per [RFC3539]; however, unlike [RFC6614], it is based on UDP and therefore does not have head-of-line blocking issues.
If this specification is indeed selected for advancement to Standards Track, certificate verification options ([RFC6614], Section 2.3, point 2) will need to be refined. Another experimental characteristic of this specification is the question of key management between RADIUS/DTLS peers. RADIUS/UDP only allowed for manual key management, i.e., distribution of a shared secret between a client and a server. RADIUS/DTLS allows manual distribution of long-term proofs of peer identity, by using TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509 certificates in a PKIX infrastructure. It remains to be seen if one of these methods will prevail or if both will find their place in real-life deployments. The authors can imagine pre-shared keys (PSKs) to be popular in small-scale deployments (Small Office, Home Office (SOHO) or isolated enterprise deployments) where scalability is not an issue and the deployment of a Certification Authority (CA) is considered too much of a hassle; however, the authors can also imagine large roaming consortia to make use of PKIX. Readers of this specification are encouraged to read the discussion of key management issues within [RFC6421] as well as [RFC4107]. It has yet to be decided whether this approach is to be chosen for Standards Track. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large-scale, real-life deployments.2. Building on Existing Foundations
Adding DTLS as a RADIUS transport protocol requires a number of changes to systems implementing standard RADIUS. This section outlines those changes, and defines new behaviors necessary to implement DTLS.
2.1. Changes to RADIUS
The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and [RFC5176]. Specifically, all of the following portions of RADIUS MUST be unchanged when using RADIUS/DTLS: * Packet format * Permitted codes * Request Authenticator calculation * Response Authenticator calculation * Minimum packet length * Maximum packet length * Attribute format * Vendor-Specific Attribute (VSA) format * Permitted data types * Calculations of dynamic attributes such as CHAP-Challenge, or Message-Authenticator. * Calculation of "obfuscated" attributes such as User-Password and Tunnel-Password. In short, the application creates a RADIUS packet via the usual methods, and then instead of sending it over a UDP socket, sends the packet to a DTLS layer for encapsulation. DTLS then acts as a transport layer for RADIUS: hence, the names "RADIUS/UDP" and "RADIUS/DTLS". The requirement that RADIUS remain largely unchanged ensures the simplest possible implementation and widest interoperability of this specification. We note that the DTLS encapsulation of RADIUS means that RADIUS packets have an additional overhead due to DTLS. Implementations MUST support sending and receiving encapsulated RADIUS packets of 4096 octets in length, with a corresponding increase in the maximum size of the encapsulated DTLS packets. This larger packet size may cause the packet to be larger than the Path MTU (PMTU), where a RADIUS/UDP packet may be smaller. See Section 5.2, below, for more discussion.
The only changes made from RADIUS/UDP to RADIUS/DTLS are the following two items: (1) The Length checks defined in [RFC2865], Section 3, MUST use the length of the decrypted DTLS data instead of the UDP packet length. They MUST treat any decrypted DTLS data octets outside the range of the Length field as padding and ignore it on reception. (2) The shared secret used to compute the MD5 integrity checks and the attribute encryption MUST be "radius/dtls". All other aspects of RADIUS are unchanged.2.2. Similarities with RADIUS/TLS
While this specification can be thought of as RADIUS/TLS over UDP instead of the Transmission Control Protocol (TCP), there are some differences between the two methods. The bulk of [RFC6614] applies to this specification, so we do not repeat it here. This section explains the differences between RADIUS/TLS and RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as follows: * We replace references to "TCP" with "UDP" * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" * We replace references to "TLS" with "DTLS" Those changes are sufficient to cover the majority of the differences between the two specifications. The next section reviews some more detailed changes from [RFC6614], giving additional commentary only where necessary.2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS
This section describes how particular sections of [RFC6614] apply to RADIUS/DTLS. Section 2.1 applies to RADIUS/DTLS, with the exception that the RADIUS/DTLS port is UDP/2083. Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be pre-configured to use RADIUS/DTLS for a given endpoint.
Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be interpreted as applying to DTLS session initiation, instead of TCP connection establishment. Item (2) applies, except for the recommendation that implementations "SHOULD" support TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical artifact of RADIUS/TLS, and it does not apply to RADIUS/DTLS. Item (3) applies to RADIUS/DTLS. Item (4) applies, except that the fixed shared secret is "radius/dtls", as described above. Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be determined from DTLS parameters, instead of relying solely on the source IP address of the packet. Section 2.5 does not apply to RADIUS/DTLS. The relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from RADIUS/UDP. Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS packet is encapsulated in one DTLS packet, and there is no "stream" of RADIUS packets inside of a TLS session. Implementors MUST enforce the requirements of [RFC2865], Section 3, for the RADIUS Length field, using the length of the decrypted DTLS data for the checks. This check replaces the RADIUS method of using the Length field from the UDP packet. Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS. Section 4 does not apply to RADIUS/DTLS. Protocol compatibility considerations are defined in this document. Section 6 applies to RADIUS/DTLS.3. Interaction with RADIUS/UDP
Transitioning to DTLS is a process that needs to be done carefully. A poorly handled transition is complex for administrators and potentially subject to security downgrade attacks. It is not sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS has no provisions for protocol negotiation, so simply disabling RADIUS/UDP would result in timeouts, lost traffic, and network instabilities. The end result of this specification is that nearly all RADIUS/UDP implementations should transition to using a secure alternative. In some cases, RADIUS/UDP may remain where IPsec is used as a transport, or where implementation and/or business reasons preclude a change.
However, we do not recommend long-term use of RADIUS/UDP outside of isolated and secure networks. This section describes how clients and servers should use RADIUS/DTLS, and how it interacts with RADIUS/UDP.3.1. DTLS Port and Packet Types
The default destination port number for RADIUS/DTLS is UDP/2083. There are no separate ports for authentication, accounting, and dynamic authorization changes. The source port is arbitrary. The text in [RFC6614], Section 3.4, describes issues surrounding the use of one port for multiple packet types. We recognize that implementations may allow the use of RADIUS/DTLS over non-standard ports. In that case, the references to UDP/2083 in this document should be read as applying to any port used for transport of RADIUS/DTLS traffic.3.2. Server Behavior
When a server receives packets on UDP/2083, all packets MUST be treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on this port. Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. Early versions of this specification permitted this behavior. It is forbidden here, as it depended on behavior in DTLS that may change without notice. Servers MUST authenticate clients. RADIUS is designed to be used by mutually trusted systems. Allowing anonymous clients would ensure privacy for RADIUS/DTLS traffic, but would negate all other security aspects of the protocol. As RADIUS has no provisions for capability signaling, there is no way for a server to indicate to a client that it should transition to using DTLS. This action has to be taken by the administrators of the two systems, using a method other than RADIUS. This method will likely be out of band, or manual configuration will need to be used. Some servers maintain a list of allowed clients per destination port. Others maintain a global list of clients that are permitted to send packets to any port. Where a client can send packets to multiple ports, the server MUST maintain a "DTLS Required" flag per client. This flag indicates whether or not the client is required to use DTLS. When set, the flag indicates that the only traffic accepted from the client is over UDP/2083. When packets are received from a
client on non-DTLS ports, for which DTLS is required, the server MUST silently discard these packets, as there is no RADIUS/UDP shared secret available. This flag will often be set by an administrator. However, if a server receives DTLS traffic from a client, it SHOULD notify the administrator that DTLS is available for that client. It MAY mark the client as "DTLS Required". It is RECOMMENDED that servers support the following Perfect Forward Secrecy (PFS) ciphersuites: o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the traffic to downbidding attacks and is NOT RECOMMENDED.4. Client Behavior
When a client sends packets to the assigned RADIUS/DTLS port, all packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this port. Clients MUST authenticate themselves to servers via credentials that are unique to each client. It is RECOMMENDED that clients support the following PFS ciphersuites: o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 RADIUS/DTLS clients SHOULD NOT probe servers to see if they support DTLS transport. Instead, clients SHOULD use DTLS as a transport layer only when administratively configured. If a client is configured to use DTLS and the server appears to be unresponsive, the client MUST NOT fall back to using RADIUS/UDP. Instead, the client should treat the server as being down. RADIUS clients often had multiple independent RADIUS implementations and/or processes that originate packets. This practice was simple to implement, but the result is that each independent subsystem must independently discover network issues or server failures. It is therefore RECOMMENDED that clients with multiple internal RADIUS sources use a local proxy as described in Section 6.1, below.
Clients may implement "pools" of servers for fail-over or load- balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS servers.5. Session Management
Where [RFC6614] can rely on the TCP state machine to perform session tracking, this specification cannot. As a result, implementations of this specification may need to perform session management of the DTLS session in the application layer. This section describes logically how this tracking is done. Implementations may choose to use the method described here, or another, equivalent method. We note that [RFC5080], Section 2.2.2, already mandates a duplicate detection cache. The session tracking described below can be seen as an extension of that cache, where entries contain DTLS sessions instead of RADIUS/UDP packets. [RFC5080], Section 2.2.2, describes how duplicate RADIUS/UDP requests result in the retransmission of a previously cached RADIUS/UDP response. Due to DTLS sequence window requirements, a server MUST NOT retransmit a previously sent DTLS packet. Instead, it should cache the RADIUS response packet, and re-process it through DTLS to create a new RADIUS/DTLS packet, every time it is necessary to retransmit a RADIUS response.5.1. Server Session Management
A RADIUS/DTLS server MUST track ongoing DTLS sessions for each, based on the following 4-tuple: * source IP address * source port * destination IP address * destination port Note that this 4-tuple is independent of IP address version (IPv4 or IPv6).
Each 4-tuple points to a unique session entry, which usually contains the following information: DTLS Session Any information required to maintain and manage the DTLS session. Last Traffic A variable containing a timestamp that indicates when this session last received valid traffic. If "Last Traffic" is not used, this variable may not exist. DTLS Data An implementation-specific variable that may contain information about the active DTLS session. This variable may be empty or nonexistent. This data will typically contain information such as idle timeouts, session lifetimes, and other implementation-specific data.5.1.1. Session Opening and Closing
Session tracking is subject to Denial-of-Service (DoS) attacks due to the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers SHOULD use the stateless cookie tracking technique described in [RFC6347], Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a ClientHello packet has been received with an appropriate Cookie value. Server implementation SHOULD have a way of tracking DTLS sessions that are partially set up. Servers MUST limit both the number and impact on resources of partial sessions. Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure Alert ([RFC5246], Section 7.2.1) or a fatal TLS Error Alert ([RFC5246], Section 7.2.2) is received. When a session is deleted due to it failing security requirements, the DTLS session MUST be closed, any TLS session resumption parameters for that session MUST be discarded, and all tracking information MUST be deleted. Sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message- Authenticator or invalid Request Authenticator. There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying session as described above. There are few reasons to communicate with a Network Access Server (NAS) that is not implementing RADIUS.
A session MUST be deleted when non-RADIUS traffic is received over it. This specification is for RADIUS, and there is no reason to allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST be deleted when RADIUS traffic fails to pass security checks. There is no reason to permit insecure networks. A session SHOULD NOT be deleted when a well-formed, but "unexpected", RADIUS packet is received over it. Future specifications may extend RADIUS/DTLS, and we do not want to forbid those specifications. The goal of the above requirements is to ensure security, while maintaining flexibility. Any security-related issue causes the connection to be closed. After the security restrictions have been applied, any unexpected traffic may be safely ignored, as it cannot cause a security issue. There is no need to close the session for unexpected but valid traffic, and the session can safely remain open. Once a DTLS session is established, a RADIUS/DTLS server SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity between the two servers. A server SHOULD also use watchdog packets from the client to determine that the session is still active. As UDP does not guarantee delivery of messages, RADIUS/DTLS servers that do not implement an application-layer watchdog MUST also maintain a "Last Traffic" timestamp per DTLS session. The granularity of this timestamp is not critical and could be limited to one-second intervals. The timestamp SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than once per interval. The timestamp MUST NOT be updated in other situations. When a session has not received a packet for a period of time, it is labeled "idle". The server SHOULD delete idle DTLS sessions after an "idle timeout". The server MAY cache the TLS session parameters, in order to provide for fast session resumption. This session "idle timeout" SHOULD be exposed to the administrator as a configurable setting. It SHOULD NOT be set to less than 60 seconds and SHOULD NOT be set to more than 600 seconds (10 minutes). The minimum useful value for this timer is determined by the application- layer watchdog mechanism defined in the following section. RADIUS/DTLS servers SHOULD also monitor the total number of open sessions. They SHOULD have a "maximum sessions" setting exposed to administrators as a configurable parameter. When this maximum is reached and a new session is started, the server MUST either drop an old session in order to open the new one or not create a new session.
RADIUS/DTLS servers SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort required to start a DTLS session with a client and increases network responsiveness. Since UDP is stateless, the potential exists for the client to initiate a new DTLS session using a particular 4-tuple, before the server has closed the old session. For security reasons, the server MUST keep the old session active until either it has received secure notification from the client that the session is closed or the server decides to close the session based on idle timeouts. Taking any other action would permit unauthenticated clients to perform a DoS attack, by reusing a 4-tuple and thus causing the server to close an active (and authenticated) DTLS session. As a result, servers MUST ignore any attempts to reuse an existing 4-tuple from an active session. This requirement can likely be reached by simply processing the packet through the existing session, as with any other packet received via that 4-tuple. Non-compliant, or unexpected packets will be ignored by the DTLS layer. The above requirement is mitigated by the suggestion in Section 6.1, below, that the client use a local proxy for all RADIUS traffic. That proxy can then track the ports that it uses and ensure that reuse of 4-tuples is avoided. The exact process by which this tracking is done is outside of the scope of this document.5.2. Client Session Management
Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU between the client and server, prior to sending any RADIUS traffic. Once a DTLS session is established, a RADIUS/DTLS client SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity between the two systems. RADIUS/DTLS clients SHOULD also use the application-layer watchdog algorithm defined in [RFC3539] to determine server responsiveness. The Status-Server packet defined in [RFC5997] SHOULD be used as the "watchdog packet" in any application-layer watchdog algorithm. RADIUS/DTLS clients SHOULD proactively close sessions when they have been idle for a period of time. Clients SHOULD close a session when the DTLS Heartbeat algorithm indicates that the session is no longer active. Clients SHOULD close a session when no traffic other than watchdog packets and (possibly) watchdog responses has been sent for three watchdog timeouts. This behavior ensures that clients do not waste resources on the server by causing it to track idle sessions.
When a client fails to implement both DTLS Heartbeats and watchdog packets, it has no way of knowing that a DTLS session has been closed. Therefore, there is the possibility that the server closes the session without the client knowing. When that happens, the client may later transmit packets in a session, and those packets will be ignored by the server. The client is then forced to time out those packets and then the session, leading to delays and network instabilities. For these reasons, it is RECOMMENDED that all DTLS sessions be configured to use DTLS Heartbeats and/or watchdog packets. DTLS sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message-Authenticator or invalid Response Authenticator. There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying DTLS session. RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS packets to different servers from the same source socket. This practice causes increased complexity in the client application and increases the potential for security breaches due to implementation issues. RADIUS/DTLS clients SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort required to start a DTLS session with a server and increases network responsiveness.6. Implementation Guidelines
The text above describes the protocol. In this section, we give additional implementation guidelines. These guidelines are not part of the protocol, but they may help implementors create simple, secure, and interoperable implementations. Where a TLS-PSK method is used, implementations MUST support keys of at least 16 octets in length. Implementations SHOULD support key lengths of 32 octets and SHOULD allow for longer keys. The key data MUST be capable of being any value (0 through 255, inclusive). Implementations MUST NOT limit themselves to using textual keys. It is RECOMMENDED that the administration interface allow for the keys to be entered as human-readable strings in hex format.
When creating keys for use with PSK ciphersuites, it is RECOMMENDED that keys be derived from a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) instead of administrators inventing keys on their own. If managing keys is too complicated, a certificate-based TLS method SHOULD be used instead.6.1. Client Implementations
RADIUS/DTLS clients should use connected sockets where possible. Use of connected sockets means that the underlying kernel tracks the sessions, so that the client subsystem does not need to manage multiple sessions on one socket. RADIUS/DTLS clients should use a single source (IP + port) when sending packets to a particular RADIUS/DTLS server. Doing so minimizes the number of DTLS session setups. It also ensures that information about the home server state is discovered only once. In practice, this means that RADIUS/DTLS clients with multiple internal RADIUS sources should use a local proxy that arbitrates all RADIUS traffic between the client and all servers. The proxy should accept traffic only from the authorized subsystems on the client machine and should proxy that traffic to known servers. Each authorized subsystem should include an attribute that uniquely identifies that subsystem to the proxy, so that the proxy can apply origin-specific proxy rules and security policies. We suggest using NAS-Identifier for this purpose. The local proxy should be able to interact with multiple servers at the same time. There is no requirement that each server have its own unique proxy on the client, as that would be inefficient. The suggestion to use a local proxy means that there is only one process that discovers network and/or connectivity issues with a server. If each client subsystem communicated directly with a server, issues with that server would have to be discovered independently by each subsystem. The side effect would be increased delays in re-routing traffic, error reporting, and network instabilities. Each client subsystem can include a subsystem-specific NAS-Identifier in each request. The format of this attribute is implementation- specific. The proxy should verify that the request originated from the local system, ideally via a loopback address. The proxy MUST then rewrite any subsystem-specific NAS-Identifier to a NAS- Identifier that identifies the client as a whole, or, remove the NAS- Identifier entirely and replace it with NAS-IP-Address or NAS- IPv6-Address.
In traditional RADIUS, the cost to set up a new "session" between a client and server was minimal. The client subsystem could simply open a port, send a packet, wait for the response, and then close the port. With RADIUS/DTLS, the connection setup is significantly more expensive. In addition, there may be a requirement to use DTLS in order to communicate with a server, as RADIUS/UDP may not be supported by that server. The knowledge of what protocol to use is best managed by a dedicated RADIUS subsystem, rather than by each individual subsystem on the client.6.2. Server Implementations
RADIUS/DTLS servers should not use connected sockets to read DTLS packets from a client. This recommendation exists because a connected UDP socket will accept packets only from one source IP address and port. This limitation would prevent the server from accepting packets from multiple clients on the same port.7. Diameter Considerations
This specification defines a transport layer for RADIUS. It makes no other changes to the RADIUS protocol. As a result, there are no Diameter considerations.8. IANA Considerations
No new RADIUS attributes or packet codes are defined. IANA has updated the "Service Name and Transport Protocol Port Number Registry". The entries corresponding to port service name "radsec", port number "2083", and transport protocol "UDP" have been updated as follows: o Assignee: IESG o Contact: IETF Chair o Reference: This document o Assignment Notes: The UDP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/TLS, prior to issuance of this RFC.9. Implementation Status
This section records the status of known implementations of RADIUS/DTLS at the time of writing, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to assist the IETF in its decision processes in progressing Internet- Drafts to RFCs.9.1. Radsecproxy
Organization: Radsecproxy URL: https://software.uninett.no/radsecproxy/ Maturity: Widely used software based on early versions of this document. The use of the DTLS functionality is not clear. Coverage: The bulk of this specification is implemented, based on earlier versions of this document. Exact revisions that were implemented are unknown. Licensing: Freely distributable with acknowledgment. Implementation experience: No comments from implementors.9.2. jradius
Organization: Coova URL: http://www.coova.org/JRadius/RadSec Maturity: Production software based on early versions of this document. The use of the DTLS functionality is not clear. Coverage: The bulk of this specification is implemented, based on earlier versions of this document. Exact revisions that were implemented are unknown. Licensing: Freely distributable with requirement to redistribute source. Implementation experience: No comments from implementors.10. Security Considerations
The bulk of this specification is devoted to discussing security considerations related to RADIUS. However, we discuss a few additional issues here.
This specification relies on the existing DTLS, RADIUS/UDP, and RADIUS/TLS specifications. As a result, all security considerations for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the TLS and RADIUS security issues discussed in [RFC6614] also apply to this specification. Most of the security considerations for RADIUS apply to the RADIUS portion of the specification. However, many security considerations raised in the RADIUS documents are related to RADIUS encryption and authorization. Those issues are largely mitigated when DTLS is used as a transport method. The issues that are not mitigated by this specification are related to the RADIUS packet format and handling, which is unchanged in this specification. This specification also suggests that implementations use a session tracking table. This table is an extension of the duplicate detection cache mandated in [RFC5080], Section 2.2.2. The changes given here are that DTLS-specific information is tracked for each table entry. Section 5.1.1, above, describes steps to mitigate any DoS issues that result from tracking additional information. The fixed shared secret given above in Section 2.2.1 is acceptable only when DTLS is used with a non-null encryption method. When a DTLS session uses a null encryption method due to misconfiguration or implementation error, all of the RADIUS traffic will be readable by an observer. Therefore, implementations MUST NOT use null encryption methods for RADIUS/DTLS. For systems that perform protocol-based firewalling and/or filtering, it is RECOMMENDED that they be configured to permit only DTLS over the RADIUS/DTLS port.10.1. Crypto-Agility
Section 4.2 of [RFC6421] makes a number of recommendations about security properties of new RADIUS proposals. All of those recommendations are satisfied by using DTLS as the transport layer. Section 4.3 of [RFC6421] makes a number of recommendations about backwards compatibility with RADIUS. Section 3, above, addresses these concerns in detail. Section 4.4 of [RFC6421] recommends that change control be ceded to the IETF, and that interoperability is possible. Both requirements are satisfied.
Section 4.5 of [RFC6421] requires that the new security methods apply to all packet types. This requirement is satisfied by allowing DTLS to be used for all RADIUS traffic. In addition, Section 3, above, addresses concerns about documenting the transition from legacy RADIUS to crypto-agile RADIUS. Section 4.6 of [RFC6421] requires automated key management. This requirement is satisfied by using DTLS key management.10.2. Legacy RADIUS Security
We reiterate here the poor security of the legacy RADIUS protocol. We suggest that RADIUS clients and servers implement either this specification or [RFC6614]. New attacks on MD5 have appeared over the past few years, and there is a distinct possibility that MD5 may be completely broken in the near future. Such a break would mean that RADIUS/UDP was completely insecure. The existence of fast and cheap attacks on MD5 could result in a loss of all network security that depends on RADIUS. Attackers could obtain user passwords and possibly gain complete network access. We cannot overstate the disastrous consequences of a successful attack on RADIUS. We also caution implementors (especially client implementors) about using RADIUS/DTLS. It may be tempting to use the shared secret as the basis for a TLS-PSK method and to leave the user interface otherwise unchanged. This practice MUST NOT be used. The administrator MUST be given the option to use DTLS. Any shared secret used for RADIUS/UDP MUST NOT be used for DTLS. Reusing a shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of the benefits found by using DTLS. RADIUS/DTLS client implementors MUST expose a configuration that allows the administrator to choose the ciphersuite. Where certificates are used, RADIUS/DTLS client implementors MUST expose a configuration that allows an administrator to configure all certificates necessary for certificate-based authentication. These certificates include client, server, and root certificates. TLS-PSK methods are susceptible to dictionary attacks. Section 6, above, recommends deriving TLS-PSK keys from a Cryptographically Secure Pseudorandom Number Generator (CSPRNG), which makes dictionary attacks significantly more difficult. Servers SHOULD track failed client connections by TLS-PSK ID and block TLS-PSK IDs that seem to be attempting brute-force searches of the keyspace.
The historic RADIUS practice of using shared secrets (here, PSKs) that are minor variations of words is NOT RECOMMENDED, as it would negate all of the security of DTLS.10.3. Resource Exhaustion
The use of DTLS allows DoS attacks and resource-exhaustion attacks that were not possible in RADIUS/UDP. These attacks are similar to those described in [RFC6614], Section 6, for TCP. Session tracking, as described in Section 5.1, can result in resource exhaustion. Therefore, servers MUST limit the absolute number of sessions that they track. When the total number of sessions tracked is going to exceed the configured limit, servers MAY free up resources by closing the session that has been idle for the longest time. Doing so may free up idle resources that then allow the server to accept a new session. Servers MUST limit the number of partially open DTLS sessions. These limits SHOULD be exposed to the administrator as configurable settings.10.4. Client-Server Authentication with DTLS
We expect that the initial deployment of DTLS will follow the RADIUS/UDP model of statically configured client-server relationships. The specification for dynamic discovery of RADIUS servers is under development, so we will not address that here. Static configuration of client-server relationships for RADIUS/UDP means that a client has a fixed IP address for a server and a shared secret used to authenticate traffic sent to that address. The server in turn has a fixed IP address for a client and a shared secret used to authenticate traffic from that address. This model needs to be extended for RADIUS/DTLS. Instead of a shared secret, TLS credentials MUST be used by each party to authenticate the other. The issue of identity is more problematic. As with RADIUS/UDP, IP addresses may be used as a key to determine the authentication credentials that a client will present to a server or which credentials a server will accept from a client. This is the fixed IP address model of RADIUS/UDP, with the shared secret replaced by TLS credentials.
There are, however, additional considerations with RADIUS/DTLS. When a client is configured with a hostname for a server, the server may present to the client a certificate containing a hostname. The client MUST then verify that the hostnames match. Any mismatch is a security violation, and the connection MUST be closed. A RADIUS/DTLS server MAY be configured with a "wildcard" IP address match for clients, instead of a unique fixed IP address for each client. In that case, clients MUST be individually configured with a unique certificate. When the server receives a connection from a client, it MUST determine client identity from the client certificate, and MUST authenticate (or not) the client based on that certificate. See [RFC6614], Section 2.4, for a discussion of how to match a certificate to a client identity. However, servers SHOULD use IP address filtering to minimize the possibility of attacks. That is, they SHOULD permit clients only from a limited IP address range or ranges. They SHOULD silently discard all traffic from outside of those ranges. Since the client-server relationship is static, the authentication credentials for that relationship must also be statically configured. That is, a client connecting to a DTLS server SHOULD be pre- configured with the server's credentials (e.g., PSK or certificate). If the server fails to present the correct credentials, the DTLS session MUST be closed. Each server SHOULD be pre-configured with sufficient information to authenticate connecting clients. The requirement for clients to be individually configured with a unique certificate can be met by using a private CA for certificates used in RADIUS/DTLS environments. If a client were configured to use a public CA, then it could accept as valid any server that has a certificate signed by that CA. While the traffic would be secure from third-party observers, the server would, however, have unrestricted access to all of the RADIUS traffic, including all user credentials and passwords. Therefore, clients SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer. Instead, the clients SHOULD start off with an empty CA list. The addition of a CA SHOULD be done only when manually configured by an administrator.
This scenario is the opposite of web browsers, where they are pre- configured with many known CAs. The goal there is security from third-party observers, but also the ability to communicate with any unknown site that presents a signed certificate. In contrast, the goal of RADIUS/DTLS is both security from third-party observers and the ability to communicate with only a small set of well-known servers. This requirement does not prevent clients from using hostnames instead of IP addresses for locating a particular server. Instead, it means that the credentials for that server should be pre- configured on the client, and associated with that hostname. This requirement does suggest that in the absence of a specification for dynamic discovery, clients SHOULD use only those servers that have been manually configured by an administrator.10.5. Network Address Translation
Network Address Translation (NAT) is fundamentally incompatible with RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the shared secret for the client, and NAT hides many clients behind one source IP address. As a result, RADIUS/UDP clients cannot be located behind a NAT gateway. In addition, port reuse on a NAT gateway means that packets from different clients may appear to come from the same source port on the NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from one source IP/port combination, followed by the reception of a RADIUS/UDP packet from that same source IP/port combination. If this behavior is allowed, then the server would have an inconsistent view of the client's security profile, allowing an attacker to choose the most insecure method. If more than one client is located behind a NAT gateway, then every client behind the NAT MUST use a secure transport such as TLS or DTLS. As discussed below, a method for uniquely identifying each client MUST be used.10.6. Wildcard Clients
Some RADIUS server implementations allow for "wildcard" clients -- that is, clients with an IPv4 netmask of other than 32 or an IPv6 netmask of other than 128. That practice is not recommended for RADIUS/UDP, as it means multiple clients will use the same shared secret.
The use of RADIUS/DTLS can allow for the safe usage of wildcards. When RADIUS/DTLS is used with wildcards, clients MUST be uniquely identified using TLS parameters, and any certificate or PSK used MUST be unique to each client.10.7. Session Closing
Section 5.1.1, above, requires that DTLS sessions be closed when the transported RADIUS packets are malformed or fail the authenticator checks. The reason is that the session is expected to be used for transport of RADIUS packets only. Any non-RADIUS traffic on that session means the other party is misbehaving and is a potential security risk. Similarly, any RADIUS traffic failing authentication vector or Message-Authenticator validation means that two parties do not have a common shared secret, and the session is therefore unauthenticated and insecure. We wish to avoid the situation where a third party can send well- formed RADIUS packets that cause a DTLS session to close. Therefore, in other situations, the session SHOULD remain open in the face of non-conformant packets.10.8. Client Subsystems
Many traditional clients treat RADIUS as subsystem-specific. That is, each subsystem on the client has its own RADIUS implementation and configuration. These independent implementations work for simple systems, but break down for RADIUS when multiple servers, fail-over, and load-balancing are required. They have even worse issues when DTLS is enabled. As noted in Section 6.1, above, clients SHOULD use a local proxy that arbitrates all RADIUS traffic between the client and all servers. This proxy will encapsulate all knowledge about servers, including security policies, fail-over, and load-balancing. All client subsystems SHOULD communicate with this local proxy, ideally over a loopback address. The requirements on using strong shared secrets still apply. The benefit of this configuration is that there is one place in the client that arbitrates all RADIUS traffic. Subsystems that do not implement DTLS can remain unaware of DTLS. DTLS sessions opened by the proxy can remain open for long periods of time, even when client subsystems are restarted. The proxy can do RADIUS/UDP to some servers and RADIUS/DTLS to others.
Delegation of responsibilities and separation of tasks are important security principles. By moving all RADIUS/DTLS knowledge to a DTLS- aware proxy, security analysis becomes simpler, and enforcement of correct security becomes easier.11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, August 2010. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012. [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.
11.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011. [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, July 2013. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996. [MD5Break] Wang, X. and H. Yu, "How to Break MD5 and Other Hash Functions", EUROCRYPT '05 Proceedings of the 24th annual international conference on Theory and Applications of Cryptographic Techniques, pp. 19-35, ISBN 3-540-25910-4, 2005.Acknowledgments
Parts of the text in Section 3 defining the Request and Response Authenticators were taken with minor edits from [RFC2865], Section 3.Author's Address
Alan DeKok The FreeRADIUS Server Project URI: http://freeradius.org EMail: firstname.lastname@example.com


text:
COVID-19 Delaying Rare Disease and Gene Therapy Trials, Pharma Execs Say
While the ongoing COVID-19 pandemic won't have much of an impact on cash available for new biotech startups, it has begun to cause delays in the development of gene therapies to treat a variety of rare diseases.
That's the consensus of industry experts who spoke in a May 26 webinar hosted by the events organizer Terrapinn, producer of the annual World Orphan Drug Congress.
The one-hour event featured Sander van Deventer, executive vice president of research and product development at Amsterdam-based uniQure, and an operating partner at Forbion; Thomas Bols, head of government affairs and public policy at PTC Therapeutics; and Lance Weed, an industry consultant.
Speaking about COVID-19 from a strictly venture capital perspective, van Deventer said the financial chaos unleashed by the pandemic has had far less of an impact on biotech than on other key sectors of the global economy.
"We are, of course, not directly dependent on consumer demand. In this case, that's a good thing," he said. "Investors in biotech are used to working with loss-making companies. Also, managing delays and hurdles is business as usual.
"There is no single successful biotech company that I've been involved with that hasn't had major periods of delays and hurdles," he added. "We are used to managing timelines and budgets, and adapting rapidly to changing situations."
Van Deventer played a critical role in the development of both Remicade (infliximab), the world's first commercial monoclonal antibody, and Glybera, a gene therapy by uniQure that in 2012 won a five-year marketing authorization from the European Union to treat hyperlipoproteinemia type 1.
Remicade is used to treat Crohn's disease, ulcerative colitis, rheumatoid arthritis, ankylosing spondylitis and other rare disorders. Glybera never received U.S. approval, and was withdrawn from the market in 2017 after it proved to be a commercial failure.
COVID-19 raises specific operational challenges to rare disease clinical trials that can force delays, van Deventer said, such as slow enrollment, limited access to hospitals, and missing data.
Reasons for optimism
Particularly vulnerable are trials targeting patients with a higher-risk profile; these will require specific strategies to be assessed on a case-by-case basis.
"This has certainly been true for gene therapy clinical trials," van Deventer said, without giving examples. "Transplant trials have been almost halted because of the pandemic. And I already know of some planned clinical trials that have run into major delays."
Asked about financing of future gene therapy trials, he added: "We do not foresee a shortage of venture capital, but rather a shift of capital from public to private investments. Companies with a short capital runway [meaning the time until a venture runs out of money] and a lack of news flow because of delayed clinical trials will run into problems — and the hurdle to engage for new deals with pharma will become significantly higher."
PTC has trials underway in rare disorders that include Duchenne muscular dystrophy, ovarian cancer, spinal muscular atrophy (SMA), and Bols said he sees reasons to be optimistic amid the gloom and doom of current headlines.
"The overall pharmaceutical sector shows positive growth, despite the pandemic," he said. "We have to count our blessings in these very difficult times. Yes, there are some negative elements, but I think the future looked bright before — and still looks reasonably bright."
In fact, Bols said, the COVID-19 crisis is actually an opportunity for the biopharma industry, and especially for companies pursuing cell and gene therapies.
"If there's one thing that makes this crisis clear, it's the importance of innovation. A lot of companies, small and big, are frantically working to come up with a vaccine or a therapy to counter COVID-19. This really underlines the need for innovation, and the role our industry is playing to come up with a solution."
Gene therapy price tag still an issue
In the meantime, he said, clinical trials are being delayed by about six months on average.
"There are definitely hurdles in starting new trials," Bols said. "A lot of companies are working offline, like we're doing now. But for certain activities like manufacturing, you really have to be in your facilities."
One fear that never materialized, he said, is that regulatory authorities such as the U.S. Food and Drug Administration (FDA) and the European Medicines Agency (EMA) would be so overwhelmed with the COVID-19 crisis that they'd ignore other pressing issues.
That hasn't happened.
"All these lessons learned for COVID-19 can be extrapolated to the development of medicines overall," Bols said. "As everybody knows, there's a real need for speeding up the system and getting treatments to patients in a much more efficient way."
Even so, "one worrying element we've seen over the last couple of weeks is that non-COVID-19 patients really have difficulty getting access to their treatments because hospitals were overwhelmed," he said. "There's a real fear among patients who can't get their treatments, and that needs to be addressed."
Another contentious issue is the sky-high prices for gene therapies. When uniQure introduced Glybera in 2012, it had a price tag of $1.2 million per patient. Five years later, by the time it was withdrawn, the single-dose treatment had been administered to a total of 31 patients.
Currently, the world's most expensive drug is the Novartis gene therapy Zolgensma, which treats children at to age 2 with SMA. It retails for $2.125 million for a single treatment.
"The amount charged for some of these gene therapies was already controversial," Bols said. "Now that we're going into a recession and governments are spending trillions on supporting the economy, I can foresee discussions around price will become even more acrimonious."


text:
[Boycott - Academic]
inminds25 July 2011
On Tuesday 14th June 2011 human rights activists came together to oppose the visit of Israeli historian Benny Morris to the London School of Economics.
Benny Morris is well known for his racist views of Arabs and Muslims, his support and whitewashing of ethnic cleansing and his justification of genocide.
Every single state in the United States had in place a scalp bounty law that would stipulate the fee the state would pay for the murder of an Indian, any Indian - it didn't matter, it was a clear policy of genocide, The payment scale was graduated with the murder of an adult male Indian achieving the highest reward, but even murdering a baby Indian would secure a good reward.
Between Columbus's arrival in 1492 and the massacre at wounded knee in 1891 98% of the Indigenous population had been wiped out and 97.5% of their land had been stolen.
In an interview with the Israeli newspaper Haartez in 2004, Benny Morris justifies this crime against humanity saying that
He justifies it as a means to an end, he says
On 9th April 1948 soldiers of the Irgun, a Zionist terror group, commanded by Menachem Begin, entered the Palestinian village of Deir Yassin. They slaughtered 250-300 men, women and children in cold blood. Their bodies were purposely mutilated to terrorise other Palestinians into fleeing their homes before they suffered similar massacres.
The Irgun, having proved itself, became part of the Israeli army. And its leader Menachem Begin went on to become the Prime Minister of Israel.
In fact he says Ben Gurion didn't go far enough
To this day the relentless quest to ethnically cleanse Palestinians from the land between the River Jordan and the Sea is still going on. Only now it is less 'noticeable' to the outside world, with coded terms such as 'transfer' and creating of 'security zones' being used to mean ethnic cleansing.
But this isn't enough for Benny Morris, he proposes that in the future Arab citizens of Israel will also need to be ethnically cleansed because they have more children than Jewish citizens and their numbers will become an existential threat to the Jewish state. He says
In February 2010 the Cambridge University Israel Society cancelled Benny Morris's scheduled talk and issued a statement saying that they
And what's more the LSE awarded those attending the talk with credits that count towards the CDP Continuing Professional Development Certification which is a requirement of Government, professional and trade institutions. Apparently they see attendance of Benny Morris's talk as a way of fulfilling your professional requirements of updating your skills and knowledge.
The security arrangements were unprecedented for what was after all a public lecture by a historian promoting his book. Attendees had to pre-register days in advance of the event, providing personal details including their address and then if they qualified for a ticket, on the day they had to bring a photo id like a passport or driving licence before they would be allowed in. The actual venue for the event was kept secret until 24 hours beforehand. Bags were strictly banned, and handbags and coats were searched before entry.
Activists had made the decision before hand that they would allow Benny Morris to speak uninterrupted. There was a silent protest inside the hall with people walking out with stickers over their mouths reading "Morris is a racist".
Many people who were not part of any protest also just walked out, they had had enough of Morris's opinions presented as history.
Security paranoia continued to the end of the talk when the audience were kept kettled inside the hall whilst Benny Morris was escorted out of the hall and out of the LSE.
In Benny Morris's own words:
As the video evidence shows, this is a total figment of his imagination, unfortunately such fabrications are not restricted to his personal encounters and cloud his whole work as a historian.
Watch the video or see the stills above and decide for yourself if there is a shred of truth in Benny Morris's account of what happened.
In the 'best' Zionist tradition, others like Melanie Phillips have continued, where Morris stopped, in adding their own embellishments to the story in their own reporting of the encounter which they never witnessed. Melanie Phillips writes for the Daily Mail newspaper and is a regular panelist on BBC's Question Time (BBC One) and The Moral Maze (BBC Radio 4), her shoddy journalism is clearly a reflection on the publications and on the programmes that pay her to spout her lies.
Source: www.inminds.co.uk


text:
Everyone should aim to have a cash reserve.
Provided by Brower Financial Group
We all would love to have a little extra cash on hand for emergencies. Saving up that cash can be a challenge – but with a little effort, that challenge can be met.
Imagine a 30-year-old couple with no real savings.
Let's call them Kurt and Diana. Together, they earn about $8,000 a month, but their household finances are being squeezed by education debt, rent, and the high cost of living in an affluent metro area. They have about $300 in the bank between them, and they just learned they have a baby on the way. Their need to save has never been greater. How can they do it?
They have many options for building their fund, more than they first assume.
Kurt has an old dirt bike gathering dust in his dad's garage, and he is no longer into off-road motorcycling. Even in its dusty condition, it could easily be sold for more than $1,500. They each have gym memberships; Kurt drops his and Diana switches to a cheaper gym, leading to a 12-month savings of $500.
Kurt also explores the possibility of working weekends or evenings as a barista in addition to his full-time job, a move that could bring in a couple of thousand dollars in the next few months. The pair sense they have a federal tax refund coming – and the average I.R.S. refund for the 2015 tax year was $2,860. They could put some or all of a four-figure refund toward their emergency fund, rather than toward paying down their student loans.1
Ideally, Kurt and Diana's emergency fund should be $25,000 or more (the equivalent of 3 or more months of living expenses). No, they are not going to come close to that this year. Or next year. They have started, though, and it looks as if they will soon have a few thousand dollars set aside for emergencies. Even having $1,000 could ease many acute financial pains.
There are numerous potential ways to boost your emergency fund.
Some are simple: save $5 or $10 a week and deposit it, eat out less, drop those memberships and subscriptions, sell something, save the money the I.R.S. hands back to you. Some require more ingenuity and energy: getting a part-time job for supplemental income, renting out a room.
Perhaps the easiest way of all is to create an automatic transfer of a small portion of your paycheck into a dedicated emergency savings account each month. Saving will seem painless this way, and when you pay off a debt, you can direct the money you used each month to reduce it into your emergency fund instead.
This material was prepared by MarketingPro, Inc., and does not necessarily represent the views of the presenting party, nor their affiliates. This information has been derived from sources believed to be accurate. Please note – investing involves risk, and past performance is no guarantee of future results. The publisher is not engaged in rendering legal, accounting or other professional services. If assistance is needed, the reader is advised to engage the services of a competent professional. This information should not be construed as investment, tax or legal advice and may not be relied on for the purpose of avoiding any Federal tax penalty. This is neither a solicitation nor recommendation to purchase or sell any investment or insurance product or service, and should not be relied upon as such. All indices are unmanaged and are not illustrative of any particular investment.
1 – fool.com/retirement/2017/02/26/how-big-is-the-average-americans-tax-refund.aspx [2/26/17]


text:
Saturn's fluctuating F ring
Released today, this image acquired by NASA's Cassini spacecraft shows some interesting structures forming within Saturn's thinnest but most dynamic ring.
Of Saturn's countless ring structures the F ring may very well be the most dynamic, if not the most fascinating. Orbiting Saturn just outside the edge of the A ring at a distance of 140,000 km (87,000 miles), the F ring is a hazy, ropy band of fine ice particles that shift, twist and occasionally gather into bright clumps… only to drift apart once more.
The F ring can range in width from 30 to 500 km (20-500 miles), depending on what's going on in and outside of it.
The image above, originally captured by Cassini on June 28 and released today by the Cassini Imaging Central Laboratory for Operations (CICLOPS), shows a particularly bright clump of material at the outer edge of the F ring, as well as some finer structures and streamers forming within the inner bands. Due to the lighting geometry its thought that the clumps are mostly composed of dusty material.
The features seen here are likely due to the ring's interactions with passing shepherd moons—such as the 148-km-wide Prometheus—or with small moonlets embedded within the ring itself. Mostly made of fine particles of dust and ice smaller than those found in smoke, the material orbiting within the F ring is extremely susceptible to external gravitational influences.
Original image scale is 4 km (3 miles) per pixel.
See more images from the entire Cassini mission on the CICLOPS site here (and for a look at more interesting ring dynamics check out these recent Cassini images of my personal favorite moon, Daphnis.)
Source: Universe Today


text:
Robert H. Bremner, professor emeritus, Ohio State University, died on September 7, 2002. He is survived by his wife, Catherine, and two daughters, Ann and Sue.
He received his BA from Baldwin Wallace College, and the MA and PhD from Ohio State University. After civilian service in the U.S. War Department and the American Red Cross in World War II, he taught in the history department of Ohio State University from 1946 to 1980, focusing on social thought, social welfare, philanthropy, and poverty.
Yet Bob Bremner was not a narrow specialist, and had an amazing catholicity of interests to include literature, art, architecture, towns, and cities and, always, their people. Among his many publications are From the Depths: The Discovery of Poverty in the United States (1956), American Philanthropy (1960),Children and Youth in America: A Documentary History (1970), and The Public Good: Philanthropy and Welfare in the Civil War (1980). His many awards included fellowships from the North Atlantic Treaty Organization, the National Endowment for the Humanities, the Charles Warren Center at Harvard University, and the Rockefeller Foundation. For his graduate and undergraduate teaching he received Ohio State's Alumni Award for Distinguished Teaching.
Bremner formally retired in 1980, but continued to research, write, and always stay connected to his students even through his last days. In 1989, as a tribute to his importance in their lives, Bremner's graduate students dedicated a festschrift in his honor, entitled For the General Welfare: Essays in Honor of Robert H. Bremner. Bob Bremner contributed to the historical profession, serving on the editorial board of the American Historical Review, chairing the Social Welfare History Group, serving as president of the Ohio Academy of History, and was a member of President's Science Advisory Committee, and the Panel on Federal Programs for Youth of the National Academy of Science.
For all of his professional accomplishments he was, above all else, a modest and humble man who was always interested in the welfare of his graduate students. Never an entrepreneurial academic "scrambler" concerned with status, self-promotion, or bathing in the glory of his own ego, Bob Bremner was a superb and profoundly dedicated teacher who would have wanted to be remembered for that more than anything else. He directed 40 graduate students toward their doctorate in history. He was a professor's professor who encouraged, inspired, and supported his graduate students' endeavors with energy, wisdom, insight, patience, and, finally, deep humanity. His family reported that in his last days in the hospital he asked about his students by name. He and his wife and life companion, Kay, never forgot their students, maintaining an interest in those who had long finished their graduate work at OSU, following their careers and their lives with affection, letters, gifts, and cards. They entertained small legions of graduate students at their home, and in numerous restaurant or professional convention outings which became joyous, informal seminars on industrial and public architecture, city planning, the history of Ohio small towns and villages, and on such diversions as neighborhood taverns as social history.
As a teacher he was especially skilled in explication of text: to listen to him find new insights in William Graham Sumner, analyze the broader significance of Henry George, explicate Thorstein Veblen on work and craftsmanship, or analyze Biblical notions of philanthropy were treats for his students' minds. He loved the term "turning a phrase"; he was a master stylist, and his criticism of written drafts gave ample evidence of concision and wit, always leaving room for students to expand, explore, and enhance their research and writing. His classroom demeanor was calm, modest, unassuming, and self-possessed, but beneath that gentle exterior resided a mind of steel and the muted strength of a classroom lion. In presenting ideas to his students he would read a particular passage several times, with different emphases on certain words or phrases, creating italics with his voice to make a point about interpretation. A gifted lecturer and seminar leader, he was strongest in substantive analysis and downplayed flamboyant theatrics, but always saved room for subtle and muted humor and irony which he expressed with a twinkle in his eyes and a calm and at times mischievous smile on his face. Bob's graduate students developed a loyalty to this gentle and great professor that can best be described as tenacious, even ferocious. He never forgot his students, and, in the circularity of life, we shall never forget him.
—, Kenyon College
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. Attribution must provide author name, article title, Perspectives on History, date of publication, and a link to this page. This license applies only to the article, not to text or images used here by permission.


text:
Dead End
It's certainly what one might call chutzpah. First, Egyptian security forces kill more than seventy people (mainly Islamists) in one night, demonstrators against the removal of the democratically elected President Morsi. Several hundred were also injured, in some cases severely, by shots in the chest and the head.
Then the interior minister of the military-imposed government announces that the pro-Morsi rallies will be broken up – by force if necessary – by the security forces, once Mubarak's most reliable men, so as to put an end to the violence on Egypt's streets at last.
The new regime is no longer even attempting to give itself a fig leaf of legitimization. The only hope is that the furore of the January 2011 revolution will be re-sparked among Egypt's young people, preventing the country from falling back into days thought long gone, three years after Mubarak's fall.
False political tactics
Armed forces chief Sisi was wrong to think he could depose Morsi simply by reading a statement, followed by a swift return to business as usual. Two almost equal camps are now facing off in Egypt, and Sisi's clumsy manoeuvring has only widened the gulf between them. He surely cannot believe in earnest that the country will settle down of its own accord in the current situation.
Sisi cannot put Morsi back into power, and the Muslim Brothers are standing firm on Morsi's reinstatement. He was freely elected, after all. Either Sisi's gunmen and stick-wielders beat the demonstrating Muslim Brothers into submission, or Sisi's own position is at stake.
Should resistance come together against Sisi in the army, his successor might make concessions to the Muslim Brothers, for instance offering them a referendum on Morsi.
In the long term, the 3 July coup could trigger what the Turkish army's ultimatum of 28 February 1997 did – a much smaller putsch, with the army dethroning Turkey's first Islamist prime minister, Necmettin Erbakan. That led to a cleansing process among Turkish Islamists, paving the way to Erdogan's later rise to power.
In the wake of its blood-drenched weekend, however, Egypt is marching in the other direction. The fronts are now rigidly opposed and the country has reached a dead end – into which Sisi has led it.
Rainer Hermann
© Frankfurter Allgemeine Zeitung / Qantara.de 2013
Translated from the German by Katy Derbyshire
Editor: Lewis Gropp/Qantara.de